In the process of conceiving a web application framework, I spent some time pond
ID: 652050 • Letter: I
Question
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 POSTrequests. Imagine every form POSTing 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.
Explanation / Answer
In most REST APIs, the type of object is not embedded in the payload. That is the job of the resource resolver. Your "master registrar" is equivalent to the typical path resolver found in web servers, except for using embedded types instead of paths.
So instead of your format:
POST /
{
topic:
{
property1: "value1",
property2: "value2",
...
}
}
use this one:
POST /topics
{
property1: "value1",
property2: "value2",
...
}
This will keep your design DRY while also leveraging standard built-in code as much as possible.
As far as the spec goes, POST is the "everything else" method, used for any processing which does not fit the semantics of GET, PUT, PATCH and DELETE. So you would not be violating the letter of the spec, but you may still end up confusing potential clients of your services because of the non-standard API.
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.