Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RESTful APIs, the big lie

mmikowski.github.io

Post reply on HN
Print view View original

11–20 of 22 posts

Re: RESTful APIs, the big lie

#11

Post by dozzie »

toyg wrote: post #8
dozzie wrote: post #6

Earlier quoted context omitted.

> [...] 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 ma…

> 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 in…

> [...] 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.

Re: RESTful APIs, the big lie

#12

Post by dozzie »

btreecat wrote: post #10
dozzie wrote: post #6

Earlier quoted context omitted.

> [...] 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 ma…

>There's no search in these. >The only HTTP verb that can sensibly carry anything beside "create", "destroy", and "retrieve" commands is POST. So what you are saying is that a search or query is fundamentally different from the idea of "retrieve" provided by the GET verb?

Of course it is different. GET is meant to retrieve a specific resource. Search results are not a resource, they are computation result.

Also, how would you specify the query and search options? Mix those in query string portion? Or encode them? (And how?)

Re: RESTful APIs, the big lie

#13

Post by toyg »

dozzie wrote: post #11
toyg wrote: post #8

Earlier quoted context omitted.

> 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 in…

> [...] 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 cli…

> Microsoft hit the spot twenty years ago with XML-RPC.

Well then, why are we even arguing about this? You like pasta, I like pizza, and never the twain shall meet. REST was born out of rejection for XML-RPC (and SOAP, which was its logical evolution once The Enterprise got involved).

If you like XML-RPC, by all means keep using it. I just don't see the point in advocating (as TFA does) that people should abandon working on REST implementations in order to embrace what is basically JSON-RPC, i.e. a completely different thing from a philosophical and design perspective.

(I've ignored the ad-hominems and bad guesses on my work history. Can we keep it civil?)

Re: RESTful APIs, the big lie

#14

Post by dozzie »

toyg wrote: post #13
dozzie wrote: post #11

Earlier quoted context omitted.

> [...] 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 cli…

> Microsoft hit the spot twenty years ago with XML-RPC. Well then, why are we even arguing about this? You like pasta, I like pizza, and never the twain shall meet. REST was born out of rejection for XML-RPC (and SOAP, which was its logical evolution once The Enterprise got involved). If you like XML-RPC, by all means keep using it. I just don't see the point in advocating (as TFA does) that people should abandon wor…

> REST was born out of rejection for XML-RPC (and SOAP, which was its logical evolution once The Enterprise got involved).

Not quite. REST was born out of rejection for SOAP, not XML-RPC. It addressed following issues (after Paul Prescod's article, http://www.prescod.net/rest/rest_vs_soap_overview/):

* SOAP didn't address objects with URIs, so you couldn't integrate your services with RDF and semantic web; RDF and SemWeb didn't boot very well, so I wouldn't call it much of a problem today.

* SOAP development was driven by software vendors instead of academics. This point presumably implies that SOAP and WSDL were a bloated piles of crap (which SOAP and WSDL are indeed).

* Prescod stated that "mechanism, not policy" results in a more flexible design, which is funny, because REST is more a policy (architectural style), with SOAP being now a well-defined, if complex, mechanism.

And now tell me, which of these people are taking into consideration when they build their REST APIs? I would say none. Most often they simply cram several operations on several resources, serializing data to JSON and calling it a day.

Re: RESTful APIs, the big lie

#15

Post by cxhartmann »

toyg wrote: post #8
dozzie wrote: post #6

Earlier quoted context omitted.

> [...] 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 ma…

> 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 in…

HTTP SEARCH PROPOSAL : https://tools.ietf.org/html/draft-snell-search-method-00

Re: RESTful APIs, the big lie

#16

Post by coldtea »

toyg wrote: post #5

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 pr…

>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.

Re: RESTful APIs, the big lie

#17

Post by coldtea »

toyg wrote: post #8
dozzie wrote: post #6

Earlier quoted context omitted.

> [...] 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 ma…

> 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 in…

>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.

Sorry, did Computer Science change the last few years and RPC went out of style?

What "problems and wars we all know" RPC has? Nothing that doesn't go with the field, and isn't already the same (or worse) in REST.

RPC is a basic CS notion that will always be around -- the same way garbage collection, floating point math, functional programming, regular expressions, etc will be.

It not some faulty fad that went away.

>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

It just forces you to overload HTTP verbs, verbs that people don't use in the first place (even web developers knew and used GET and POST but not PUT and DELETE -- outside of REST and some specialty domains that is), that might or might not match your business logic.

>From that point of view, something like SOAP is a perfectly respectable protocol and you should use that instead.

Slippery slope fallacy.

Re: RESTful APIs, the big lie

#18

Post by WorldWideWayne »

toyg wrote: post #5

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 pr…

> 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.

Re: RESTful APIs, the big lie

#19

Post by coldtea »

toyg wrote: post #13
dozzie wrote: post #11

Earlier quoted context omitted.

> [...] 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 cli…

> Microsoft hit the spot twenty years ago with XML-RPC. Well then, why are we even arguing about this? You like pasta, I like pizza, and never the twain shall meet. REST was born out of rejection for XML-RPC (and SOAP, which was its logical evolution once The Enterprise got involved). If you like XML-RPC, by all means keep using it. I just don't see the point in advocating (as TFA does) that people should abandon wor…

>REST was born out of rejection for XML-RPC (and SOAP, which was its logical evolution once The Enterprise got involved).

Not even remotely true. REST was a re-invention of XML-RPC wheel -- for the web and using baroque HTTP conventions that were meant for documents and hyperlinks.

XML-RPC was never rejected because it never caught much on in the first place. On the enterprise they pushed for SOAP at the same time, and on the web it wasn't yet a period were anybody really did rpc (plain AJAX, REST or any other kind).

In terms of simplicity it goes like: XML-RPC -> REST -> abyss -> SOAP, with XML-RPC and REST both on the far "simpler" end of the scale compared to SOAP.

Re: RESTful APIs, the big lie

#20

Post by coldtea »

dozzie wrote: post #12
btreecat wrote: post #10

Earlier quoted context omitted.

>There's no search in these. >The only HTTP verb that can sensibly carry anything beside "create", "destroy", and "retrieve" commands is POST. So what you are saying is that a search or query is fundamentally different from the idea of "retrieve" provided by the GET verb?

Of course it is different. GET is meant to retrieve a specific resource. Search results are not a resource, they are computation result. Also, how would you specify the query and search options? Mix those in query string portion? Or encode them? (And how?)

Also consider image search (e.g. what Google does). You'd base64 the image on the GET query string?
Post reply on HN