Simple Routes & Config Routes

[nathan...@fairfaxmedia.com.au]

hey all

just putting it out there but since playing with the swagger integration (yes i will be sharing) ive been looking at how the routes are defined and how the simple routes are automatically mapped

i see that for every action it generates a get, post, put, patch and delete route and then goes on to generate the routes based in the config file.

im not sure how everyone else maps their actions but mine are all defined in a crud style like getUser, updateUser, deleteUser, saveUser etc.... (eg https://gist.github.com/BoLaMN/2e2842d69c6a35e5f949)

so now i have 20 routes for 4 actions??

my thoughts would be to map the actionv views out something like

exports.User =
name: 'user'
description: 'defines user actions'

post:
description: 'creates a user'
run: (api, data, next) -> next()

put:
description: 'updates a user'
run: (api, data, next) -> next()

delete:
description: 'deletes a user'
run: (api, data, next) -> next()

get:
description: 'details of a user'
run: (api, data, next) -> next()

note: left out all the validators here to keep this as short as possible.

then the simple routes that are automatically generated become something like

method | route
get: /user/:id
delete: /user/:id
put: /user/:id
post: /user/:id

note: id becomes an optional path parameter serving purposes of 'findAll' or 'findOne'

to make sure we still allow the other transports beside http to talk to the api my suggestion would be to generate the other transport actions in reverse and prefix the action name based on the defined methods, eg.

saveUser: exports.User.post
updateUser: exports.User.put
deleteUser: exports.User.delete
getUser: exports.User.get

i think an approach something this would make for a more componentized\modular system instead of defining the routes automatically when most of the time for myself anyway each action only handles 1 method and the other 4 maps routes arent used.

the only other way i can see doing something similar too this idea would be to define something like this

module.exports =
initialize: (api, next) ->
api.users =
save:
description: 'creates a user'
run: (api, data, next) -> .. cut .. next()
update:
description: 'creates a user'
run: (api, data, next) -> .. cut .. next()
...... cut

exports.User =
name: 'user'
description: 'defines user route'
run: (api, data, next) ->
switch data.method
when 'post' then api.users.save(api, data, next)
when 'put' then api.users.update(api, data, next)
..... cut

but then i believe validation, middleware etc.. would become more complex again. (do people do it this way??)

just ideas on making the routes system more crud like anyway.

cheers
--
The information contained in this e-mail message and any accompanying files
is or may be confidential. If you are not the intended recipient, any use,
dissemination, reliance, forwarding, printing or copying of this e-mail or
any attached files is unauthorised. This e-mail is subject to copyright. No
part of it should be reproduced, adapted or communicated without the
written consent of the copyright owner. If you have received this e-mail in
error please advise the sender immediately by return e-mail or telephone
and delete all copies. Fairfax Media does not guarantee the accuracy or
completeness of any information contained in this e-mail or attached files.
Internet communications are not secure, therefore Fairfax Media does not
accept legal responsibility for the contents of this message or attached
files.

[Evan Tahler]

Keep in mind that actions are used for other transports beyond HTTP.  websocket doesn't have routes... so what method should respond to WS requset to the user action?  

That's the reason that routes are unrelated to actions.  Actually, I think we should move the routes config into servers/web to make this more clear. 

[nathan...@fairfaxmedia.com.au]

Hey Evan

my thoughts on the other transports is already there?

[Evan Tahler]

Sorry, I don't understand the question.  Can you ask it another way?