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

31–40 of 224 posts

Re: Problems with RESTful APIs (2015)

#31

Post by codr4life »

andybak wrote: post #5
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…

What you just described is only the bare shell of REST. It would also apply to many types of API that don't follow REST principles. One thing this article gets right is that nobody is really RESTful because nobody knows what it means. There's usually a dollop of RPC in most APIs - and there's nothing wrong with that - but the 'pure vision' of REST is similar to the 'pure vision' of the Semantic Web. It's a dream for…

I'm fine with using ideas that make sense and rejecting the ones that don't. It's still solid advice for API design, and the most successful approach we've come up with. Doing REST to the letter always turns into some kind of modern art installation with lots of hammers looking for nails; this is the technology department, religion is down the corridor. I have full confidence that the authors considered these ideas, not laws.

Re: Problems with RESTful APIs (2015)

#32

Post by jquast »

teddyh wrote: post #14
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.

Previously using HATEOAS, gathering large amounts of data, say some kind of reporting dashboard, required a great deal of seperate HTTP requests, it was far less efficient in I/O and performance than without.

Anyway, I find GraphQL provides this solution very kindly, I can ask questions about the great big world, and request only specific fields, like a user's name, the names of their 10 closest friends and their availability status, all in a single call.

With HATEOAS this could be 10 to 20 calls, and maybe contain extra information in the response I'm not necessarily interested in.

Re: Problems with RESTful APIs (2015)

#33

Post by dandelany »

rantanplan wrote: post #28
dandelany wrote: post #17

Earlier quoted context omitted.

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?

I'm not claiming that REST is a protocol. I'm saying that the de facto state of the REST paradigm today is analogous to some protocols which have been twisted to support use-cases far beyond what their designers intended, in ways that make purists squeamish, but make developers happy that their shit works.

Re: Problems with RESTful APIs (2015)

#34

Post by other_herbert »

jquast wrote: post #32
teddyh wrote: post #14

Earlier quoted context omitted.

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.

Previously using HATEOAS, gathering large amounts of data, say some kind of reporting dashboard, required a great deal of seperate HTTP requests, it was far less efficient in I/O and performance than without. Anyway, I find GraphQL provides this solution very kindly, I can ask questions about the great big world, and request only specific fields, like a user's name, the names of their 10 closest friends and their ava…

I was looking for someone to mention graphql... For lots of cases this is a great way to reduce the client calls and give the client exactly what it is asking for..

Re: Problems with RESTful APIs (2015)

#35

Post by rantanplan »

dandelany wrote: post #33
rantanplan wrote: post #28

Earlier quoted context omitted.

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?

I'm not claiming that REST is a protocol. I'm saying that the de facto state of the REST paradigm today is analogous to some protocols which have been twisted to support use-cases far beyond what their designers intended, in ways that make purists squeamish, but make developers happy that their shit works.

> use-cases far beyond what their designers intended

OK, I get what you're saying. Problem is that as far as I can see REST is perfect for S3-like services, Maps(?) and slightly more than basic CRUD applications.

You are bound to discover its limits very soon. The gazillions of books and blogposts out there heralding it as a serious interface are not helping either.

BTW, I don't know about other people criticizing, I am definitely not a purist. But after ~10 years of dealing with REST in various capacities(startups to Enterprises), I am a bit tired and can't wait for something to replace it.

Re: Problems with RESTful APIs (2015)

#37

Post by ravibala1 »

Seems like most of the comments hate on REST because it's been poorly implemented by an API developer. Why is the solution yet another API protocol (JSONpure) and not stricter enforcement? (Idealistic i know...)

The point about SOAP not requiring documentation makes no sense either. You'd still need to document what the underlying fields in the various endpoints are. (We build against a lot of terribly documented SOAP APIs and its pure torture)

In terms of PUT (and PATCH) not being extensively used - it comes down to your use case. For the idempotent micro-services we build APIs against, there is a massive difference in the behavior expected for POST/PUT/PATCH and it would be pretty burdensome (and limiting) to have to create parsing code on the server for POST.

Re: Problems with RESTful APIs (2015)

#38

Post by awinder » 

  Ever notice how nobody calls their API “RESTpure”? Instead
  they call it “RESTful” or “RESTish”. That’s because nobody
  can agree on what all the methods, payloads, and response
  codes really mean.
These reasons have nothing to do with why people don't use the term "REST" versus using "RESTful". RESTful is the compromised approach, cribbing some of the concepts outlined in Fielding's paper but dispensing with others. Among those are a de-emphasis of linking, and a url naming pattern. HTTP verbs describe types of actions in RESTful lingo, versus meaning something about the different idempotency & safety guarantees of a request in the REST paper.

In REST, I'm not sure that a lot of these issues are that contentious. I do think that some of the emphasized points in "RESTful" design practice can create more contention in API design, but that's the downfall of that one pattern, it has nothing to do with what Fielding described.

  No governing body - at least to my knowledge - has convened to set things straight
IANA has a ton of info on link relations and they're thoroughly speced. IETF has tons of API / REST related specifications. Profiles allow for defining what your data means, there's open source curated lists of these profiles already so if you were designing an API you could even leverage existing works to make your design easier.

  Roy is probably a great guy and he certainly had a lot of
  great ideas. However, I don’t believe that RESTful APIs was
  one of them.
This statement is just downright hysterical given the relative disparity here. So much of the web is owed to Fielding's paper, there's been countless books and blog posts and just human man hours devoted to the work he's done. Who's this guy? Why is this such a trend in blog posts in this community, it just looks foolish and comes off as petty...

Re: Problems with RESTful APIs (2015)

#39

Post by Manishearth »

> Ever notice how nobody calls their API “RESTpure”? Instead they call it “RESTful” or “RESTish”.

Isn't that just because RESTful is a play on words?

> For example, most web browsers have limited support for PUT or DELETE.

Really? How? If anything browsers restrict these methods to exactly how they should be used (DELETE can't have postdata but PUT can).

It's true that folks don't use PUT/DELETE much (the alternative works perfectly well though), but to me that's because they're unnecessary complexity, not browser support.

Re: Problems with RESTful APIs (2015)

#40

Post by ianamartin »

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…

Can you not imagine a REST-ful use case where the DELETE options should never work?

Come on, person.

I don' know about you, but I provide REST stuff where the only option is update.

Post reply on HN