I was listening to a podcast today about creating APIs and how to handle endpoints for model relationships.
Some people create an additional method on their Posts controller to handle the new comment (PostsController@comment), while others might create a Comments controller with a method for the specific post (CommentsController@post). On the podcast they talked about a third camp that creates a separate controller for the relationship itself, called PostCommentsController.
What's your method?
Use the standard CREATE, DELETE, POST, UPDATE methods.
/post/${id}/comment/create
To clarify I mean the PUT, POST, GET etc request types. So don't tag /create etc on the end but do make sure that the methods, based on the request types, are available at the same end point. :)
I don't actually follow the question, but that's because if we're talking POST as in form data, NONE OF THE ABOVE.
I tend to code using the 'one index to rule them all' methodology and as such any page can perform ANY action... creating, deleting, updating, etc, etc, the PATH has not a blasted thing to do with it, the FORM DATA DOES.
which is why client side the only thing you might see in the URI is the comment's # as a on-page link. /post/postname#commentnumber
But in terms of server iteration, this isn't even a thing. This way you cannot risk people creating hotlinks to things like deletion and creation. You HAVE to send postData.
SO many XSS exploits wouldn't even exist if people just showed a little common sense and stopped putting commands and direct links into their URI's.
Mark
formerly known as M
I would either use
/post/<id>/commentlike the first option (but singular
post), or/post/<id>/comment/addwhich I've been told is bad practice because http method
POSTalready means 'add', but I like the redundancy, makes it more explicit and less error-prone.