In the process of conceiving a web application framework, I spent some time pondering the notion of RESTful paths. If I wanted to create e.g. a new topic, I might send a POST request to /topics. The parameters thereof might be something like: { topic: { body: 'Body' } }
As such, the type of resource being created can be inferred from the parameters. Since there is the top-level item 'topic', we can logically ascertain that the request is to create a topic.
For me, the strange thing is that POST create is the one action that falls outside of the notion of either a singular resource or a collection. It is arguably neither. Sure, you're adding to a collection, but in contrast to say a GET index
you are not retrieving any part of that collection, and the state of that collection to a large extent is irrelevant. In contrast to a GET
, PUT/PATCH
, or a DELETE
, you are not retrieving a singular item based on an identifier. You are creating an item where one does not exist.
I conceived of a "master registrar" service that would respond to all incoming POST
requests. Imagine every form POST
ing to /
, with the master registrar determining the intended resource based on the params, and deferring to services that exist for the purpose of persisting a resource based on those params.
In fact, for any non-GET action, the paths become irrelevant. They don't seem to have an important semantic purpose. A user is not going to link to a form's action URL. Even in the case of PUT
, PATCH
, or DELETE
The type of resource being created or the resource being modified can be inferred from the parameters. For example, if we were editing a topic versus creating one, the parameters might be { topic: { id: 1, body: 'New Body'} }
. The presence of an ID in the parameters indicates that the topic in question already exists and should be retrieved foremost.
I don't know if this is RESTful or not. Regardless, I cannot see why this approach is invalid or inadvisable. Given my caution and naivete, however, I'd like to know why it might be.