I have read through the threads you referenced again and I think I can
see where you are coming from.
I think that part of the problem is that examples of REST rarely seem
to include the parts of the user interaction where the user requests
an HTML form to be used to create/update/delete. The examples seem to
assume knowledge at the client end that would enable a PUT, POST or
DELETE to be generated without any prior GET. I can see how this is
possible but this is not generally the case with HTML interactions,
hence the need to encode additional information in the GET to
- return a list and return a create form
- return a read-only version and return an edit form (with an option
Taking the list vs create case, which of the following forms of GET
would you prefer to see (assuming .../default/locations returns a
It would be a shame if you selected the last one :-) as I think that
all the "locations" requests going through the same controller/action
has a certain elegance. Whichever you select, I assume that "search"
would be handled similarly.
Taking the read-only vs update/delete case, which of the following
forms of GET would you prefer to see (assuming .../default/locations/1
returns a read-only version, i.e. not a form):
As for the "POST" or send part of the interaction, you suggest
overloading POST via a CGI parameter (after the ?). This seems
equivalent to overloading via a URI element (?_rest_method=DELETE
versus /delete) but I think a parameter is better as it leaves a
cleaner URI. The only downside is a lack of symmetry between the GET
and POST for create and update but I don't think that is significant.
The revision would mean that the POST for create and update would look
...and the action determined by the id parameter (present and non-zero
for an update, absent or non-zero for a create).
Depending upon your responses, I would be happy to write up an
alternative example to enable people to compare.
What do you think?