7 ms·

RESTful APIs, the big lie

13 points by ricny046 11y ago

antimora 11y ago
JSON-pure API? Do you mean SOAP but with JSON instead of XML?
- mjevans 11y ago
  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/ https://xkcd.com/927/ (Standards) comes to mind.
- dozzie 11y ago
  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 11y ago
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.
- dozzie 11y ago
  > [...] 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.
  - toyg 11y 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. We'll just have to disagree there. In any case, if you find REST restrictive, fine, go ahead and do your RPC. Just don't try to tell me that it's anything other than RPC, with all the problems and warts we all know. The value in REST is exactly that it forces you to simplify your interface down to basic verbs that everyone can understand and work with; if you can't do that, if additional complexity is unavoidable, then REST is not for you and you should be aware that your application is now officially complex, maybe too complex to be a public API. From that point of view, something like SOAP is a perfectly respectable protocol and you should use that instead.
    - dozzie 11y ago
      > [...] fine, go ahead and do your RPC. Just don't try to tell me that it's anything other than RPC, with all the problems and warts we all know. Why the heck do you think that "lol, you use RPC" would be an insult? Because you clearly send this message with your tone. I put RPC wherever I need an operation(s) to be called remotely. And yes, I do use dedicated RPC protocols (namely, XML-RPC, for popularity of its clients). I rarely create things that boil down to being a CRUD database interface, so I find REST very limiting. > From that point of view, something like SOAP is a perfectly respectable protocol and you should use that instead. Apparently you haven't worked with SOAP. No, it's not respectable. It's overcomplicated itself, it uses overcomplicated format (XML with namespaces), and its tooling is overcomplicated, too (e.g. try to control how WSDL looks like, so you can swap implementation languages; or try to create WSDL beforehand, and then implement its backend in a language of your choice). Really, in HTTP-based remote call protocols (this includes REST!), Microsoft hit the spot twenty years ago with XML-RPC. The only two things missing are null/None/undef encoding and named procedure arguments.

13 points by ricny046 11y ago

antimora 11y ago

JSON-pure API? Do you mean SOAP but with JSON instead of XML?

mjevans 11y ago
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/ https://xkcd.com/927/ (Standards) comes to mind.
dozzie 11y ago
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 11y ago

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.

dozzie 11y ago
> [...] 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.
- toyg 11y 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. We'll just have to disagree there. In any case, if you find REST restrictive, fine, go ahead and do your RPC. Just don't try to tell me that it's anything other than RPC, with all the problems and warts we all know. The value in REST is exactly that it forces you to simplify your interface down to basic verbs that everyone can understand and work with; if you can't do that, if additional complexity is unavoidable, then REST is not for you and you should be aware that your application is now officially complex, maybe too complex to be a public API. From that point of view, something like SOAP is a perfectly respectable protocol and you should use that instead.
  - dozzie 11y ago
    > [...] fine, go ahead and do your RPC. Just don't try to tell me that it's anything other than RPC, with all the problems and warts we all know. Why the heck do you think that "lol, you use RPC" would be an insult? Because you clearly send this message with your tone. I put RPC wherever I need an operation(s) to be called remotely. And yes, I do use dedicated RPC protocols (namely, XML-RPC, for popularity of its clients). I rarely create things that boil down to being a CRUD database interface, so I find REST very limiting. > From that point of view, something like SOAP is a perfectly respectable protocol and you should use that instead. Apparently you haven't worked with SOAP. No, it's not respectable. It's overcomplicated itself, it uses overcomplicated format (XML with namespaces), and its tooling is overcomplicated, too (e.g. try to control how WSDL looks like, so you can swap implementation languages; or try to create WSDL beforehand, and then implement its backend in a language of your choice). Really, in HTTP-based remote call protocols (this includes REST!), Microsoft hit the spot twenty years ago with XML-RPC. The only two things missing are null/None/undef encoding and named procedure arguments.