Routing & URL

routes.txt

RAILS WAY FOR REFERENCE  -------------------------------------------------------

@note This was designed "web client" first, not really good for APIs.

HTTP       Verb Path         Action          Used for
GET        /photos           photos#index    display a list of all photos
GET        /photos/new       photos#new      return an HTML form for creating a new photo
POST       /photos           photos#create   create a new photo
GET        /photos/:id       photos#show     display a specific photo
GET        /photos/:id/edit  photos#edit     return an HTML form for editing a photo
PATCH/PUT  /photos/:id       photos#update   update a specific photo
DELETE     /photos/:id       photos#destroy  delete a specific photo


KIT API ------------------------------------------------------------------------

@note 4 actions to implement ("CRUD")

BATCH ROUTES
  @desc This is what will actually need to exist in the controllers.

  GET     /api/photos
  CREATE  /api/photos
  PATCH   /api/photos
  DELETE  /api/photos

ALIASED SINGLE ROUTES
  @desc Auto-generated through aliasing on the corresponding batch route.

  GET     /api/photos/:id
  PATCH   /api/photos/:id
  DELETE  /api/photos/:id


KIT WEB ------------------------------------------------------------------------

@note 5 actions that can be implemented, 4 that are likely needed

VIEW ORIENTED
  @desc Allow the user to interactor with the ressource
  @note It starts to get messy really fast, but these will likely be aliased to get more user friendly routes.

  GET /web/authors/:id                #show_one
  GET /web/authors                    #show_list
  GET /web/authors/_new               #return a view to create N ressources (N will most likely be 1 for most apps)
  GET /web/authors/:id/_edit          #return a view to create 1 ressource
  
  GET /web/authors/_edit?filter[id]=  #return a view to update N ressources
  
  @note The 2 first actions represent the objects themselves.
  @note The 3 last actions represent more the "forms" or "views" than an action on the object themselves)
  
  The correct semantics might be:
 
  GET /web/authors/:id                #show_one
  GET /web/authors                    #show_list
  
  GET /web/authors-forms              #return a view to create N ressources (N will most likely be 1 for most apps, the default behaviour would be `limit=1`)
  GET /web/authors-forms/:id          #return a view to update 1 ressource
  GET /web/authors-forms?id=          #return a view to update N ressources
  

ACTION ORIENTED
  @desc Perform the action & redirect.
  @note Highly suspect these will be aliases to the API routes, with a redirect instead of sending data back.
  @note We can probably make the forms obey the json-api format.

  CREATE  /web/authors
  PATCH   /web/authors
  PATCH   /web/authors/:id  (alias)
  DELETE  /web/authors
  DELETE  /web/authors/:id  (alias)


QUESTIONS ----------------------------------------------------------------------

- Should we use a prefix to differentiate between resource_name, id, actions ? ( like /authors/:id/_edit )
- Should the forms obey to the json-api format? (Seems desirable, assess doability)