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

21–30 of 224 posts

Re: Problems with RESTful APIs (2015)

#21

Post by coldtea »

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…

>I'm going to have to call bullshit on that one.

And yet you don't provide a single concrete reason. And even go on to say the non-REST way you use REST at your team.

>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 worth the effort.

Note how none of this (or even few parts of what the author of TFA described) is actually REST as defined by Roy.

Re: Problems with RESTful APIs (2015)

#22

Post by dragonwriter »

quanticle wrote: post #18
derefr wrote: post #8

The "true spirit" of REST, to me, is that there's a certain set of things you can do when creating an API that will let you re-use the huge amount of HTTP middleware that's been written and get correct (and useful!) semantics from it. Caches (browser-, edge-, and server-side-), load balancers, forward- and reverse-proxies, application-layer firewalls, etc. will all "just work" for your software if you do REST correct…

The "true spirit" of REST, to me, is that there's a certain set of things you can do when creating an API that will let you re-use the huge amount of HTTP middleware that's been written and get correct (and useful!) semantics from it. Caches (browser-, edge-, and server-side-), load balancers, forward- and reverse-proxies, application-layer firewalls, etc. will all "just work" for your software if you do REST correct…

> Doesn't that assume that the middleware also implements REST correctly?

It assumes that the middleware supports HTTP properly.

Re: Problems with RESTful APIs (2015)

#23

Post by rantanplan »

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.

Ouch. You brought a gun to a fist fight. Ok ok, SOAP/XML apis are worse. Agreed.

Re: Problems with RESTful APIs (2015)

#24

Post by coldtea »

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://…

>You can choose to follow the style (which is so much more than naming methods and URIs) or fight it.

And most people chose to ignore it -- and implement RESTful (mostly unrelated to REST as described by Roy) APIs, and no much harm has befallen them.

Re: Problems with RESTful APIs (2015)

#26

Post by codr4life »

lcw wrote: post #9
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…

Although PUT is not necessary using it for idempotent calls like it was designed to do actually helps developers using the API understand the intent of the call better. They don't have to worry about undesired consequences/side effects. Which I think is a useful pattern.

I agree that it's potentially useful, but it also adds it's share of complexity to any implementation I've come across. And most proposed uses I've seen do not obviously benefit from the idempotent approach, from my experience it often complicates the server implementation. I've found using the REST approach for URLs, separating reads from writes and using status codes a good compromise.

Re: Problems with RESTful APIs (2015)

#27

Post by codr4life »

coldtea wrote: post #21
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…

> I'm going to have to call bullshit on that one. And yet you don't provide a single concrete reason. And even go on to say the non-REST way you use REST at your team. > 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…

You might do well to read what I wrote about perfect and good enough. These are ideas, not laws.

Re: Problems with RESTful APIs (2015)

#28

Post by rantanplan »

dandelany wrote: post #17
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…

REST has "failed" in the same way that many original visions of the web/APIs/protocols have "failed" - you have a few "no-true-Scotsman" purists complaining about differences in implementation; meanwhile a great many real-world developers are quite happy and productive in a REST-like paradigm and don't particularly care that their API doesn't fit some Platonic ideal. Could things be better? No doubt. But REST (or som…

Your comparisons are not that relevant. Also comparing it to a "protocol" is the overstatement of the decade.

How many browsers do you have? 3-5?

How many REST client libraries are there?

Answer: one per service(per programming language).

What kind of protocol is that?

Re: Problems with RESTful APIs (2015)

#29

Post by codr4life »

rantanplan wrote: post #4
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…

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

It failed? When?

Re: Problems with RESTful APIs (2015)

#30

Post by dragonwriter »

jquast wrote: post #13

I think what bothers me most about REST is that the endpoint is not sufficient to get started. The schema is never known. I hate SOAP and xml-rpc, but at least you can know for sure what endpoints, parameters, and variable types are appropriate. With REST, you must have documentation or source code of the service you communicate with, they offer no discoverability. I won't use REST again. I got an opportunity to use…

> I think what bothers me most about REST is that the endpoint is not sufficient to get started. The schema is never known.

If you are actually doing REST, the interpretation of a resource representation is fully specified by the media-type (insofar as if there is additional schema, etc., information necessary, how to find that given the actual representation is also defined by the media type.)

Obviously, this is not true in the all-to-common REST-minus-HATEOAS.

Post reply on HN