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

11–20 of 224 posts

Re: Problems with RESTful APIs (2015)

#11

Post by rs86 »

I liked that the article made me think of using websockets for a pure JSON API, but I think it misses a lot of what is nice about rest and much of what it criticises is actually HTTP..... Rest as a set of verbs that act on resources is really useful.

I used to find it awkward to implement services in rest, as in some action that is triggered and may overlive the request cycle until I started thinking of service commands as items in a work queue that get processed by a worker. So when a service is requested I can see it as a resource being created.

Re: Problems with RESTful APIs (2015)

#12

Post by teddyh »

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 - Jon Moore: http://vimeo.com/20781278

Designing a RESTful Web API: http://blog.luisrei.com/articles/rest.html

Re: Problems with RESTful APIs (2015)

#13

Post by jquast »

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 GraphQL recently in my profession and all of my projects will be using it in the future.

Re: Problems with RESTful APIs (2015)

#14

Post by teddyh »

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…

REST without using hypertext data types is indeed non-discoverable. You have experienced why REST is almost pointless without HATEOAS. Next time, look into using REST with HATEOAS, as it was intended to be used.

Re: Problems with RESTful APIs (2015)

#16

Post by WillPostForFood »

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…

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.

Re: Problems with RESTful APIs (2015)

#17

Post by dandelany »

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…

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 something like it) is largely "the way things are built" these days and most people don't mind. Calling it a failure is quite a stretch IMO.

Re: Problems with RESTful APIs (2015)

#18

Post by quanticle »

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 correctly, and won't have any 
    weird edge-cases.
Doesn't that assume that the middleware also implements REST correctly? As the article points out, there are all too many HTTP libraries that only support GET and POST, not the more "esoteric" verbs like PUT and DELETE.

Re: Problems with RESTful APIs (2015)

#19

Post by fleitz »

Here's the rub, you're completely right, the problem is for the most part when you don't have rockstars making JSON Pure APIs you end up with half of HTTP redone in some god awful manner.

I once worked with an API where they implemented their own HTTPS and because their own https didn't support gzip they removed quotes from json keys to save bandwidth. JSON pure probably is better when working with knowledgeable people but REST is better than what most people come up with and when not following REST

Re: Problems with RESTful APIs (2015)

#20

Post by gkoberger »

The promise of APIs is simple. Send some data, something happens, get some data back.

But at about hour 4 of wrangling a bearer token to authenticate your barely-documentated PATCH request that is returning a strange error about your application/x-www-form-urlencoded body, you start to realize that APIs in theory are very different from APIs in practice.

(That being said, I don't love the "solution". It's very simplistic and it seems like the author doesn't really understand what he dislike about APIs. I don't think we need another protocol, but rather higher-level tools for dealing with them.)

Post reply on HN