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

Problems with RESTful APIs (2015)

mmikowski.github.io

Post reply on HN
Print view View original

91–100 of 224 posts

Re: Problems with RESTful APIs (2015)

#91

Post by weq »

beachy wrote: post #60

This article is largely bollocks. 1) Almost every gripe in it refers to bad implementations, not bad specs. 2) It doesn't even mention HATEOAS. I'm no fan, but usually arguments about whether your API is REST or not revolve around how/whether you've done HATEOAS. 3) The rest of it is pulp tech writing that sounds like it was vomited out to meet some kind of publishing deadline. Case in point: > Consider, for example,…

Spoiler alert, if the majority of implementions are "bad", or dont mention HATEOAS then the article is totally justified.

REST will live on in memory, as an idea of a utpoia, just not in implementation.

Re: Problems with RESTful APIs (2015)

#93

Post by edwinyzh »

teddyh wrote: post #12

In my opinion, you can't really understand REST until you understand HATEOAS - the two concepts work together and REST (and the restrictions it imposes) isn't really very meaningful without HATEOAS. Twilio Conference 2011: Steve Klabnik, Everything You Know About REST Is Wrong: http://vimeo.com/30764565 REST APIs must be hypertext-driven: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... Hypermedia APIs…

The first time I heard about HATEOAS is from the authoer of intercooler.js, and these tow of his blog posts were insiprable:

HATEOAS is for Humans :(http://intercoolerjs.org/2016/01/18/rescuing-rest.html)

Rescuing REST From the API Winter: (http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...)

Re: Problems with RESTful APIs (2015)

#94

Post by Waterluvian »

When I was given the task of defining how our multi-robot server would interface with our user interfaces, I eventually settled on REST. Most of what I knew about REST had been obtained that week. I implemented something pretty vanilla with Django and it all felt pretty elegant. I didn't have to worry about defining a protocol, there was pretty much already one for me:

- GET, PUT, POST, DELETE (I learned there were others but were kind of niche/obsolete)

- 200s for success, 400s for client (request) error, 500s for server error.

It was all nice and worked great (and still does, years later).

But over time numerous people started told me that no it's actually all wrong for one reason or another. I've heard that I should never use anything except GET and POST. That I should ALWAYS return a 200 and provide error metadata as a response if there actually was an error. That POST is actually meant for updates and PUT is meant for new entities. That the opposite is true. That neither is true and I should always use POST for any mutation of state. etc.

I feel like I had success because I approached it from a position of ignorance, meaning I just implemented a simple, sane REST API and was none the wiser that I was doing it wrong.

Re: Problems with RESTful APIs (2015)

#95

Post by edejong »

WillPostForFood wrote: post #16
rantanplan wrote: post #4

Earlier quoted context omitted.

> I've been trying hard for years to find a reason to bother with PUT, but so far I've found it not worth the effort. And right there, at your final sentence, you basically described why REST has more or less failed. GET and POST are useless for implementing a complete application protocol. You'd basically overload these http verbs to the point where you would implement your own protocol. And that's what most people…

Maybe it is fair to call REST a failure in that it is flawed, and there aren't perfect implementations. But I just had to go through a SOAP XML integration, and it was ten times more painful than the worst REST experience I've had. So I still see REST as one of the biggest tech wins in a long time.

Really? I made one yesterday based on a WSDL from a customer. The whole API was auto generated in type safe Scala in seconds. After adding authentication configuration and some sensible timeouts, I had the whole thing running in two hours. The SOAPui auto generated a mock test and load tests with which I could mimic specific weird responses.

The REST API I had to forward through however had no good documentation, no client library, so I was forced to write json serializers and reverse engineer the code. Overall, when you have a well written SOAP interface (rare, admitted), development time can be greatly reduced.

Re: Problems with RESTful APIs (2015)

#96

Post by imafish »

> most client and server applications don’t support all verbs or response codes for the HTTP protocol. For example, most web browsers have limited support for PUT or DELETE. And many server applications often don’t properly support these methods either.

I have never, as in ever, stumbled upon this problem. So I googled it. It turns out that what he means is that HTML forms don't support PUT and DELETE. In a world where everybody uses JavaScript anyway, I cannot see how this is a flaw in RESTful API's. It might be a flaw in HTML forms though.

Re: Problems with RESTful APIs (2015)

#97

Post by amorphid »

alganet wrote: post #7
codr4life wrote: post #2

I'm going to have to call bullshit on that one. REST is one of the more successful strategies we've come up with for connecting systems, this is just another case of letting perfect stand in the way of good enough. Using GET for non-destructive operations and POST for updates and deletes is a nice, portable compromise. I've been trying hard for years to find a reason to bother with PUT, but so far I've found it not w…

You don't need PUT nor DELETE. It is OK to use POST[1]. Most people don't understand REST. It is not a standard, it is not a set of practices. It is an architectural style and the web is built on it. You can choose to follow the style (which is so much more than naming methods and URIs) or fight it. The dissertation is pretty clear about it[2], but most people ignore it because there are no code samples. [1]: http://…

When given the choice, I only use PUT. Personally, I like idempotent requests.

Re: Problems with RESTful APIs (2015)

#99

Post by Animats »

From the article: "The way forward: JSON-Pure APIs".

I can see a little of this. It's better today to send parameters in HTTP data in JSON format rather than encoding them in the URL. If you're doing a pure GET, you can send parameters with the URL, but anything that changes server side state probably shouldn't be done that way.

Of course, what's happening is that the JSON crowd is re-inventing SOAP, but, whatever.

Re: Problems with RESTful APIs (2015)

#100

Post by icebraining »

weq wrote: post #91
beachy wrote: post #60

This article is largely bollocks. 1) Almost every gripe in it refers to bad implementations, not bad specs. 2) It doesn't even mention HATEOAS. I'm no fan, but usually arguments about whether your API is REST or not revolve around how/whether you've done HATEOAS. 3) The rest of it is pulp tech writing that sounds like it was vomited out to meet some kind of publishing deadline. Case in point: > Consider, for example,…

Spoiler alert, if the majority of implementions are "bad", or dont mention HATEOAS then the article is totally justified. REST will live on in memory, as an idea of a utpoia, just not in implementation.

Nope, the majority of implementations are just fine, and follow HATEOAS pretty closely: they're called "websites". You're using one of them right now.
Post reply on HN