|
> Route params _identify_ the object Well... in REST they do :-) HTTP is designed to give access to a tree of files. The REST design says "lets fully embrace the idea that we are representing our data and program state as a virtual tree of files." You can embrace or reject that to various degrees, but the closer a design is to a virtual tree of files, the more "RESTful" I say it is. In a RPC ("procedure call") paradigm, you have a collection of named procedures, each of which takes parameters/input and returns a result/output. Anything that isn't the procedure name is a parameter to the procedure. Some are mandatory parameters, and some are optional parameters, but in the most straightforward implementation of "HTTP RPC", the path indicates which procedure, and parameters to the procedure should be a HTTP parameters (or request body). Also note that in this case the HTTP status '404' would indicate the presence or absence of the RPC endpoint, like the author wanted, and the procedure would be expected to return 200 for a within-spec return value, or possibly 422 or 5xx to represent an application-level exception to be propagated to the caller. There's nothing stopping us from mixing the paradigms, and in fact nobody is forcing anyone to use any paradigm at all, since we can literally do whatever we want with the HTTP path, uri, method, and headers. But when the original article claims to be doing RPC and not REST, I think that is just sowing confusion onto the topic. |