What the author ends up proposing, as usual, is basically RPC-over-JSON. Replace JSON with XML and RPC with SOAP, and you get the sort of monster-construct the REST movement was born to fight.
This particular sentence says it all: "the message content should be independent of the transmission channel." That's the RPC dream: no matter what the pipe is, I'm sending you stuff to do. The problem, of course, is that in practice the transmission channel is never neutral: for example, HTTP and RMI are very different beasts, and in practice applications built on top of either one will end up relying on this or that assumption about the protocol, no matter how hard you try to standardize them. Same for any transmission protocol out there, really. You just have to decide when to stop trying to abstract everything away and do your work, because each additional abstraction is inevitably leaky. In this sense, REST basically tells you to stop right there and get to work. REST is not a "transmission channel", it's an application design philosophy for applications built on HTTP. End of.
Pretty much all his other objections can be fixed by using proper response codes and intelligent payloads that do not include verbs. The only verbs you need are in HTTP already - GET, POST and DELETE will cover 99% of your requirements. They make your API substantially predictable and robust. The minute you start putting verbs in payloads, you're doing RPC and you might as well use CORBA. If this is what you want, go ahead and do it, but don't say it's REST's fault if you don't understand what REST is.
> [...] GET, POST and DELETE will cover 99% of your requirements.
Hardly. There's no search in these. You end up putting your query either to
URL, which is hideous, or to request body, which is awful.
The only HTTP verb that can sensibly carry anything beside "create",
"destroy", and "retrieve" commands is POST. This equals to operation
"manipulate". And guess what? Plenty of remote interfaces use at the same
time many operations that can be called "manipulate". Sticking to merely HTTP
verbs is way, way too constraining.
> The only verbs you need are in HTTP already - GET, POST and DELETE will cover 99% of your requirements.
To really do things for arbitrary apps without getting ugly and abusing the intended semantics, you really need at least GET, QUERY (safe, retrieves a resource specified by the combination of the URI and the request body rather than just the URI like GET), POST, PUT, PATCH, and DELETE. All but QUERY and PATCH are very widely supported now, and PATCH is fairly widely supported. QUERY isn't (there are some things like it under various names, mostly overly specific and tied to WebDAV, but nothing general purpose in an RFC or in general use.)
>What the author ends up proposing, as usual, is basically RPC-over-JSON. Replace JSON with XML and RPC with SOAP, and you get the sort of monster-construct the REST movement was born to fight.
No, you just get something like XML-RPC. Which was a great and cool solution in its time. Only even simpler in this case, since XML is replaced with JSON.
Nothing to do with SOAP's faults (which were related to over-engineering and ridiculous volumes of specs) at all.
RPC-over-JSON (using HTTP) is exactly what we need and what we want to do.
Only we do it as "REST", complicating our lives trying to condense our endpoints to BS "HTTP verbs" that don't exactly match, and adding a separate off-band lane for status (HTTP STATUS codes) instead of having everything alonside the payload.
> What the author ends up proposing, as usual, is basically RPC-over-JSON [because] "message content/transmission channel."...
No he's not. The RPC pattern is a tad more specific than "any pattern that separates message content from channel". Likewise, just because you put one or more "verbs" in your payload doesn't mean you're doing RPC.
An RPC system has a much more rigid message structure that represents a function call, which is automatically marshaled via concrete client and server methods. If you're just receiving a payload and calling one or more methods based on it's contents, you're not doing RPC and you're not even touching upon any of the problems of SOAP.
The actual problems with SOAP have very little to do with the fact that messages can be serialized or that there are verbs. Here are some of the problems with SOAP:
- XML is verbose, making transmission slower.
- SOAP is a huge, complicated type system compared to JSON.
- Mapping SOAP to a given language is difficult.
- Security concerns over automatic function marshaling.
Meanwhile, you can write a JSON parser in an afternoon and it's extremely simple idioms are relatively easy to relate to a given programming language.
About all I gleaned from reading it was a big list of reasons why 'RESTful' is bad, and that the main solution was to use HTTP(s) as purely a transport layer.
What, exactly the 'solution' will look like depends on future posts... however https://xkcd.com/927/ (Standards) comes to mind.
Is it so strange? XML-RPC is simpler ancestor of SOAP. JSON-RPC is a superset
of XML-RPC (includes e.g. named parameters), defined over JSON instead of XML.
JSON-RPC doesn't have the wide spread of XML-RPC, though.
I don't see much wrong with those, and they do much better than REST, since
they already have well-defined way of signaling errors.
toyg|10 years ago
This particular sentence says it all: "the message content should be independent of the transmission channel." That's the RPC dream: no matter what the pipe is, I'm sending you stuff to do. The problem, of course, is that in practice the transmission channel is never neutral: for example, HTTP and RMI are very different beasts, and in practice applications built on top of either one will end up relying on this or that assumption about the protocol, no matter how hard you try to standardize them. Same for any transmission protocol out there, really. You just have to decide when to stop trying to abstract everything away and do your work, because each additional abstraction is inevitably leaky. In this sense, REST basically tells you to stop right there and get to work. REST is not a "transmission channel", it's an application design philosophy for applications built on HTTP. End of.
Pretty much all his other objections can be fixed by using proper response codes and intelligent payloads that do not include verbs. The only verbs you need are in HTTP already - GET, POST and DELETE will cover 99% of your requirements. They make your API substantially predictable and robust. The minute you start putting verbs in payloads, you're doing RPC and you might as well use CORBA. If this is what you want, go ahead and do it, but don't say it's REST's fault if you don't understand what REST is.
dozzie|10 years ago
Hardly. There's no search in these. You end up putting your query either to URL, which is hideous, or to request body, which is awful.
The only HTTP verb that can sensibly carry anything beside "create", "destroy", and "retrieve" commands is POST. This equals to operation "manipulate". And guess what? Plenty of remote interfaces use at the same time many operations that can be called "manipulate". Sticking to merely HTTP verbs is way, way too constraining.
dragonwriter|10 years ago
To really do things for arbitrary apps without getting ugly and abusing the intended semantics, you really need at least GET, QUERY (safe, retrieves a resource specified by the combination of the URI and the request body rather than just the URI like GET), POST, PUT, PATCH, and DELETE. All but QUERY and PATCH are very widely supported now, and PATCH is fairly widely supported. QUERY isn't (there are some things like it under various names, mostly overly specific and tied to WebDAV, but nothing general purpose in an RFC or in general use.)
coldtea|10 years ago
No, you just get something like XML-RPC. Which was a great and cool solution in its time. Only even simpler in this case, since XML is replaced with JSON.
Nothing to do with SOAP's faults (which were related to over-engineering and ridiculous volumes of specs) at all.
RPC-over-JSON (using HTTP) is exactly what we need and what we want to do.
Only we do it as "REST", complicating our lives trying to condense our endpoints to BS "HTTP verbs" that don't exactly match, and adding a separate off-band lane for status (HTTP STATUS codes) instead of having everything alonside the payload.
WorldWideWayne|10 years ago
No he's not. The RPC pattern is a tad more specific than "any pattern that separates message content from channel". Likewise, just because you put one or more "verbs" in your payload doesn't mean you're doing RPC.
An RPC system has a much more rigid message structure that represents a function call, which is automatically marshaled via concrete client and server methods. If you're just receiving a payload and calling one or more methods based on it's contents, you're not doing RPC and you're not even touching upon any of the problems of SOAP.
The actual problems with SOAP have very little to do with the fact that messages can be serialized or that there are verbs. Here are some of the problems with SOAP:
Meanwhile, you can write a JSON parser in an afternoon and it's extremely simple idioms are relatively easy to relate to a given programming language.antimora|10 years ago
mjevans|10 years ago
What, exactly the 'solution' will look like depends on future posts... however https://xkcd.com/927/ (Standards) comes to mind.
dozzie|10 years ago
I don't see much wrong with those, and they do much better than REST, since they already have well-defined way of signaling errors.