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

Most RESTful APIs aren't really RESTful

florian-kraemer.net

Post reply on HN
Print view View original

171–180 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#171

Post by kccqzy »

mixedbit wrote: post #47

When I was working on my first HTTP-based API 13 years ago, based on many comments about true REST, I decided to first study what REST should really be. I've read Fielding's paper cover to cover, I've read RESTful Web Services Cookbook from O'Reilly and then proceeded to workaround Django idioms to provide REST API. This was a bit cargo cult thinking from my end, I didn't truly understand how REST would benefit my se…

It's not just the original REST that usually has no benefits. The industry's reinterpreted version of weak REST also usually has little to no benefits. Who really cares that deleting a resource must necessarily be done with the DELETE HTTP verb rather than simply a POST?

Re: Most RESTful APIs aren't really RESTful

#173

Post by layer8 »

nchmy wrote: post #149
layer8 wrote: post #143

Earlier quoted context omitted.

Browsers are interactive clients, the opposite of automated clients. What you are saying supports the conclusion that Roy Fielding’s conception is unsuitable for non-interactive clients. However, the vast majority of real-world REST APIs are targeting automation, hence it doesn’t make sense for them to be “RESTful”.

Sorry, perhaps we're talking past each other. Fielding was absolutely not saying that his REST was the One True approach. But it DOES mean something The issue at hand here is that he coined REST and the whole world is using that term for something completely unrelated (eg an http json api). You could start writing in binary here if you thought that that would be a more appropriate way to communicate, but it wouldn't…

It may mean something, but Roy Fielding went out of his way, over many years, to not talk about the actual use cases he had in mind. It would have been easy for him to clarify that he was only talking about interactive browser applications. But he didn’t. And the people who came up with HATEOAS didn’t think he was. Nor did any of the blog articles that are espousing the alleged virtues of RESTfulness. So it’s not surprising that the term “REST” was appropriated for something else. In any case, it’s much too late to change that, it’s water down the bridge.

I’m only mildly interested in discussing hypothetical hypermedia browsers, for which Roy Fielding’s conception might be well and good (but also fairly incomplete, IMO). What developers care about is how to design HTTP-based APIs for programmatic use.

Re: Most RESTful APIs aren't really RESTful

#174

Post by hombre_fatal »

calvinmorrison wrote: post #157
eska wrote: post #108

Earlier quoted context omitted.

While I ask people whether they actually mean REST according to the paper or not, I am one of the people who refuse to just move on. The reason being that the mainstream use of the term doesn’t actually mean anything, it is not useful, and therefore not pragmatic at all. I basically say “so you actually just mean some web API, ok” and move on with that. The important difference being that I need to figure out the pec…

REST means, generally, HTTP requests with json as a result.

It also means they made some effort to use appropriate http verbs instead of GET/POST for everything, and they made an effort to organize their urls into patterns like `/things/:id/child/:child_id`.

It was probably an organic response to the complexity of SOAP/WSDL at the time, so people harping on how it's not HATEOAS kinda miss the historical context; people didn't want another WSDL.

Re: Most RESTful APIs aren't really RESTful

#176

Post by lompad »

eadmund wrote: post #134
runroader wrote: post #66

Earlier quoted context omitted.

This is more like people arguing over "proper" English, the point of language is to communicate ideas. I work for a German company and my German is not great but if I can make myself understood, that's all that's needed. Likewise, the point of an API is to allow programs, systems, and people to interoperate. If it accomplishes that goal, it's fine and not worth fighting over. If my API is supposed to rely on content-…

> This is more like people arguing over "proper" English, the point of language is to communicate ideas. ur s0 rait, eye d0nt nnno wy ne1 b0dderz tu b3 "proppr"!!!!1!! You are correct that communication is the point. Words do communicate a message. So too does disrespect for propriety: it communicates the message that the person who is ignorant or disrespectful of proper language is either uneducated or immature, and…

>misusing it just decreases clarity and hinders communication

There is no such thing as "misusing language". Language changes. It always does.

Maybe you grew up in an area of the world where it's really consistent everywhere, but in my experience I'm going to have a harder time understanding people even two to three villages away.

Because language always changes.

Words mean a particular thing at a point in time and space. At another one, they might mean something completely different. And that's fine.

You can like it or dislike it, that's up to you. However, I'd say every little bit of negative thoughts in that area only serve to make yourself miserable, since humanity and language at large just aren't consistent.

And that's ok. Be it REST, literally or even a normal word such as 'nice', which used to mean something like 'foolish'.

Again, language is inconsistent by default and meanings never stay the same for long - the more a terminus technicus gets adapted by the wider population, the more its meaning gets widened and/or changed.

One solution for this is to just say "REST in its original meaning" when referring to what is now the exception instead of the norm.

Re: Most RESTful APIs aren't really RESTful

#177

Post by mschaef »

> The core problem it addresses is client-server coupling. There are probably countless projects where a small change in a server’s URI structure required a coordinated (and often painful) deployment of multiple client applications. A HATEOAS-driven approach directly solves this by decoupling the client from the server’s namespace. This addresses the quality of evolvability.

Not sure I agree with this. All it does is move the coupling problem around. A client that doesn't understand where to find a URL in a document (or even which URL's are available for what purpose within that document) is just as bad as a client that assumes the wrong URL structure.

At some point, the client of an API needs to understand the semantics of what that API provides and how/where it provides those semantics. Moving it from a URL hierarchy to a document structure doesn't provide a huge amount of added value. (Particularly in a world where essentially all of the server API's are defined in terms of URL patterns routing to handlers. This is explicit hardcoded encouragement to think in a style in opposition to the HATEOAS philosophy.)

I also tend to think that the widespread migration of data formats from XML to JSON has worked against "Pure" REST/HATEOAS. XML had/has the benefit of a far richer type structure when compared to JSON. While JSON is easier to parse on a superficial level, doing things like identifying times, hyperlinks, etc. is more difficult due to the general lack of standardization of these things. JSON doesn't provide enough native and widespread representations of basic concepts needed for hypertext.

(This is one of those times I'd love some counterexamples. Aside from the original "present hypertext documents to humans via a browser" use case, I'd love to read more about examples of successful programmatic API's written in a purely HATEOAS style.)

Re: Most RESTful APIs aren't really RESTful

#178

Post by bravesoul2 »

JimDabell wrote: post #33
bravesoul2 wrote: post #20

Drake meme for me: REST = Hell No GQL = Hell No. RPC with status codes = Grin and point. I like to get stuff done. Imagine you are forced to organize your code filed like REST. Folder is a noun. Functions are verbs. One per folder. Etc. Would drive you nuts. Why do this for API unless the API really really fits that style (rare). GQL is expensive to parse and hides information from proxies (200 for everything)

> Imagine you are forced to organize your code filed like REST. Folder is a noun. Functions are verbs. One per folder. Etc. Would drive you nuts. That’s got nothing to do with REST. You don’t have to do that at all with a REST API. Your URLs can be completely arbitrary.

Ok I may have been wrong. I checked the thesis and couldn't see this aspect mentioned. Most of the thesis seems like stuff I agree with. Damn. I'm fighting an impression of REST I had.

Re: Most RESTful APIs aren't really RESTful

#179

Post by LoganDark »

hombre_fatal wrote: post #174
calvinmorrison wrote: post #157

Earlier quoted context omitted.

REST means, generally, HTTP requests with json as a result.

It also means they made some effort to use appropriate http verbs instead of GET/POST for everything, and they made an effort to organize their urls into patterns like `/things/:id/child/:child_id`. It was probably an organic response to the complexity of SOAP/WSDL at the time, so people harping on how it's not HATEOAS kinda miss the historical context; people didn't want another WSDL.

> It also means they made some effort to use appropriate http verbs instead of GET/POST for everything, and they made an effort to organize their urls into patterns like `/things/:id`.

No not really. A lot of people don't understand REST to be anything other than JSON over HTTP. Sometimes, the HTTP verbs thing is done as part of CRUD but actually CRUD doesn't necessarily have to do with the HTTP verbs at all and there can just be different endpoints for each operation. It's a whole mess.

Re: Most RESTful APIs aren't really RESTful

#180

Post by appreciatorBus »

oneeyedpigeon wrote: post #166
lucideer wrote: post #129

Earlier quoted context omitted.

> - CRUD actions are mapped to POST/GET/PUT/DELETE Agree on your other three but I've seen far too many "REST APIs" with update, delete & even sometimes read operations behind a POST. "SOAP-style REST" I like to call it.

> even sometimes read operations behind a POST Even worse than that, when an API like the Pinboard API (v1) uses GET for write operations!

I work with an API that uses GET for delete :)
Post reply on HN