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

171–180 of 224 posts

Re: Problems with RESTful APIs (2015)

#171

Post by naasking »

int_19h wrote: post #146
naasking wrote: post #66

Earlier quoted context omitted.

It's not worth making the distinction between idempotent and non-idempotent writes given the possibility of network partitions. Every write must be made idempotent because all you can do is retry in this case. PUT is merely an optimization on idempotent POST requests, one that will become progressively rarer as HTTPS continues to spread. POST requests can be made idempotent by binding the result of processing that re…

An insert cannot be idempotent by the very definition of the operation.

Requesting an insert can be idempotent. Each non-idempotent operation is tagged with a unique identifier, if the server doesn't have inserted data tagged under that identifier, then it performs the insert, if it does, then it returns the usual success code as if it had just performed the insert. This unique identifier is simply a durable representation of a future which I described above.

Re: Problems with RESTful APIs (2015)

#172

Post by thehardsphere »

edejong wrote: post #95
WillPostForFood wrote: post #16

Earlier quoted context omitted.

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…

In order to get the well written SOAP interface, it helps to have the right tools and be used to using them. I think that increases the barrier to entry on using SOAP, which leads to the idea that SOAP is terrible and crufty compared to REST.

I learned SOAP relatively recently, but well after it was a fad. Today, my experience would be like yours if I had to make a SOAP service with just a WSDL. But when I started out? It would take a longer for me to wrap my head around all of it. I can't imagine how confusing it would be if I had to do it all without the benefit of working on a team whose focus is a SOAP-based product. I dunno if I would know where to begin.

Compare that to REST. Even if you know next-to-nothing to start, you can do a basic REST tutorial for just about any stack in an hour, and get a basic implementation of an API up in an afternoon.

Re: Problems with RESTful APIs (2015)

#173

Post by icebraining »

fnord123 wrote: post #163
masklinn wrote: post #126

Earlier quoted context omitted.

> Maybe BetterREST. It's not better and it still is not REST. Why don't you just call it what it is: HTTP. Or maybe HTTP-RPC if you want to be more specific.

To be clear, I think we're talking about REST without HATEOAS. And I think this is better, imo, as you can write your client knowing the protocol. I've not come across a convincing description of why HATEOAS is a good thing at all. And I say this as someone who thinks capability based design is a good thing. The reasons I have against it are that 1. I think it complicates the client because it needs to discover the a…

HATEOAS is a great concept, but we can only really take advantage of it if and when we move from this troglodyte era of APIs. The fact that we still consider normal to write new "client libraries" for each new service created is just absurd. Imagine if we had to write a new browser plugin for each new site we published - that's at the level we're at on APIs!

To be more specific, HATEOAS is an essential component to comply with the Uniform Interface constraint of REST, which, as the dissertation describes, allows for decoupling and independent evolvability of the client and server.

Since we still accept the idea that client libraries and the programs that use them should be completely coupled with the services they communicate with, and it's fine to force thousands or millions of developers to update their software because an URL on some service changed, HATEOAS doesn't feel particularly useful.

Re: Problems with RESTful APIs (2015)

#174

Post by blablabla123 »

I see the point that REST is not perfect, but better than "awful". IMHO it qualifies for pretty nice:

Point 1: 200 is shorthand for 2xx. If I'm too lazy what the code is for "forbidden" or "insert something fancy here", I just return a 400. Does it's job and underlines that it's the user's fault. ;)

Point 2: PUT and DELETE worked for me very well. I remember just one project where everything had to be "tunneled" through GET. Because "exotic" toolchain/frameworks, at least there was a canonical way to do so.

Point 3: I think that's actually the nice thing about REST that its vocabulary is limited. Thinking about the pletora of unstructured HTTP XML RPCs and tons of structurally different Highlevel JS APIs for each vendor, REST seams quite relieving.

Point 4: I don't really get that. Chrome Debug works awesome, I get all the information I need. There are many tools out there for mega comfortable debugging.

Point 5: That's definitely a thing. I wish the article was only around that point.

Re: Problems with RESTful APIs (2015)

#175

Post by icebraining »

icebraining wrote: post #108
tobyjsullivan wrote: post #65

On first pass, I totally agree with the author. I haven't reviewed the proposed alternative yet but fingers crossed. That said, I think he misses the single biggest issue with REST APIs that I continuously encounter and which has caused me to consider them sub-par. Representative "State" Transfer. REST APIs are only good for transferring around the state of stateful objects. However, CRUD operations are only part of…

REST provides no identifiable mechanism for performing actions outside of CRUD operations and is, therefore, a completely impractical solution. The mechanism is identifiable once you start to really think in REST terms. The problem is that people think in RPC, and so try to shove its model instead. REST is based on names (resources), not commands. Therefore, we must implement our actions as resources. Instead of havi…

To add to my previous post: it's not like this is a weird concept; every e-commerce site out there implements this. Imagine if we followed the RPC model: the user would click on "submit", and then the browser would wait for a reply when the order was finished being delivered - multiple days later!

Obviously this is impractical, so people follow the natural REST model: they create an Order resource, then send you a link with which you can follow the status of that resource.

But bring the "API" word and suddenly all of the preconceptions push developers to implement everything as function calls.

Re: Problems with RESTful APIs (2015)

#176

Post by sandythos »

masklinn wrote: post #105
Animats wrote: post #99

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.

> Of course, what's happening is that the JSON crowd is re-inventing SOAP, but, whatever. SOAP uses schemas and the like, they just keep reinventing the same RPC as ever, except can't actually bring themselves to use the word. At least JSON-RPC is honest there, and ticks all of TFAA's box: * uses whatever's under as a trivial transport (covers 1, 3 and 6) * all data and metadata are part of the higher protocol (cover…

Hence also reinventing CORBA IIOP, DCE, Apollo NCS, Xerox Courier...

Actual innovation in this area seems to be limited to JS background data sync libs. Ironically, reference-capable protocols like CORBA anticipated this whereas flattening it all REST-style was a step backwards.

Re: Problems with RESTful APIs (2015)

#177

Post by raverbashing »

Waterluvian wrote: post #94

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

REST purism is very similar to religious extremism

There are a lot of them saying that your system is not pure REST, that it would be a joke to call it REST, that most "REST" APIs out there are not real REST and only they know the true way of doing stuff

If only they shipped something or made something work given real-world constraints

Re: Problems with RESTful APIs (2015)

#178

Post by icebraining »

k__ wrote: post #157
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,…

I thought REST didn't define much so basically every API can be REST conform. Just because HATEOAS makes REST APIs better, doesn't mean those without the use of it aren't REST. Even SOAP can be REST conform. Anyway, I guess with the rise of GraphQL, which is more strict (at least in its definition) REST will go away and we will have better dev life's.

I thought REST didn't define much

It does, it's just at a different level. REST is not a protocol, it's a set of architectural constraints, but it's well defined. Only one of the constraints (code-on-demand) is optional. HATEOAS isn't, since you need it to achieve the Uniform Interface that allows you to decouple the clients from the services.

Re: Problems with RESTful APIs (2015)

#179

Post by ffjffsfr »

blablabla123 wrote: post #174

I see the point that REST is not perfect, but better than "awful". IMHO it qualifies for pretty nice: Point 1: 200 is shorthand for 2xx. If I'm too lazy what the code is for "forbidden" or "insert something fancy here", I just return a 400. Does it's job and underlines that it's the user's fault. ;) Point 2: PUT and DELETE worked for me very well. I remember just one project where everything had to be "tunneled" thro…

> I see the point that REST is not perfect, but better than "awful".

:+1 and they are also better than what author advocates. One thing in author proposal that absolutely puts me off is this:

> JSON-Pure APIs (...) have only one response code to confirm proper receipt of a message - typically 200 OK for HTTP.

This is terrible. PLEASE do not design your API-s like this, this will confuse the hell out of all bots, browsers and everyone who depend on status codes (and that's all web clients). Your 404 error pages will be cached and stored in google, redirects will not be remembered, error pages not retried, etc etc.

I don't get the idea of json pure. Author claims that one benefit is:

> All errors, warnings, and data are placed in the JSON response payload.

But REST-ful API doesn't forbid you from returning informative error messages in json. Why not keep old HTTP semantics known by everyone and return json with informative error message?

I also think that author confuses HTTP semantics as defined in actual WEB STANDARDS with purely academic work of Roy Fielding. Meaning of status codes or methods has nothing to do with REST-ful this is just plain HTTP semantics as defined by RFC-s.

Re: Problems with RESTful APIs (2015)

#180

Post by icebraining »

halostatue wrote: post #70
mcguire wrote: post #68

Earlier quoted context omitted.

" 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. " You know that. I know that. But all the comments down to this point in the discussion have been over whether GET, PUT, POST, etc., are necessary or sufficient.

…and having implemented HATEOAS in a service (via json+hal), we’re moving far away (GraphQL) because of versioning, payload weight, and lack of flexibility. I’m sure there are things we could have done better, but the reality is that our clients need things that work differently than a “proper” REST/HATEOAS service. We tried. We failed (insomuch as delivering a working service is failure, but we know it can’t grow th…

Like any other architectural model, REST is good for some things, not for others. Versioning and payload weight seem like weird problems to have, though. Seems like JSON might have been a poor encoding for your use case.

By the way, do you have a link to that work by fishworks?

Post reply on HN