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

191–200 of 224 posts

Re: Problems with RESTful APIs (2015)

#191

Post by sebringj »

Relating to this...recently I needed to hook up a web app to a JSON RPC API and also extend that API, having to work with a legacy system. It was interesting to note that there was only one POST verb used in the entire API and the data format was always the same. At first I grumbled and was annoyed by the use of this system as it was old as hell but after some point, I was like, "oh, i don't have to worry about verbs now" or where to grab from params, query string, headers or body... so it was actually easier. I still hated it though because it wasn't REST because I was pretty biased with the status quo.

What I'm trying to say is having more choices or more ways to do something isn't necessarily a good thing as it makes it easier for people to do it so many ways that they can screw it up or just make it weird for everyone else. REST is kind of weird that way and I agree with this article for the most part.

Re: Problems with RESTful APIs (2015)

#192

Post by eranation »

paulddraper wrote: post #87
eranation wrote: post #73

Sorry for the controversial question, and I probably raised my eyebrow if I saw a candidate choose XML over JSON when taking on a recent project... but really, why JSON? No comments, no multiline, no schema. I understand that XML is bad because ____ (not cool, verbose, old school, only enterprises use it?) I am not a huge YAML fan but it seems this is the only human readable form of JSON. The lack of self describing…

JSON, as the name suggests, is easily and natively consumable by JavaScript, the only language to run natively in web browsers. And everyone uses a web browser. Ergo, if you develop an HTTP API, you should do it with JSON so it can work easily in web browsers.

Can you elaborate please?

Browsers had native XMLHttp support before they had JSON support.

The fact JSON (use to be) a subset of JavaScript and the browser runs JavaScript natively is not convincing.

Other than evil eval(jsonString) (before JSON.parse was available) which is basically asking for XSS, what benefit you get from JSON being consumable by JavaScript?

I think XMLHttp was available in browsers (in a vendor specific annoying way perhaps but still available) way before JSON.parse was available... am I missing something?

Re: Problems with RESTful APIs (2015)

#193

Post by jessaustin »

masklinn wrote: post #110
Waterluvian wrote: post #107

Earlier quoted context omitted.

I'm not sure where I misguided people that I was just doing RPC. Almost all endpoints are as you described: `/robots/robot_id/exceptions` `/maps/map_id/destinations` `/maps/map_id/areas/speed_limit_areas` Performing operations is not done via. RPC but rather POSTing a new `mission` to the queue. There's no HATEOS but that would generally be silly, since this isn't an API that requires easy discovery and consumption b…

> I'm not sure where I misguided people that I was just doing RPC. Sadly the person you respond to is an idiot, their points 1 and 3 have literally nothing to do with REST. You could have all endpoints be /435645646 yet do rest, you can have the most beautifully crafted URLs in the world and do rpc, they're orthogonal concerns. Most people do the latter, incidentally. > Performing operations is not done via. RPC but…

I'm with you on HATEOS, but I suspect OP is selling OP's system a bit short, and you're filling in the blanks in the least charitable way. The resource at "/maps/map_id/destinations", for example, probably has links to particular destinations, and those destinations probably have e.g. "modify this destination" forms. You might prefer for the URL to be "/ab129f294b", but that is your own taste rather than anything about REST. There is nothing wrong with memorable URLs.

>> Performing operations is not done via. RPC but rather POSTing a new `mission` to the queue.

> That's still RPC. Encoding your procedure calls via HTTP verbs doesn't make it not RPC, it makes it (as originally noted) leverage HTTP as more than a trivial transport.

RPC uses POST, and sometimes GET, usually to a single URL. OP is creating, modifying, and deleting resources, each at its own URL, using the proper HTTP verbs. You might be getting hung up on the fact that the "mission" resource corresponds to something conceptual rather than something physical like an individual robot? Again, that's your own taste, rather than anything about REST. Or do you mean instead that OP should invent some new verbs appropriate to robots, like MOVE or ACTUATE? That would be a bit goofy...

Re: Problems with RESTful APIs (2015)

#194

Post by user15672 »

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…

Did you really just complain that REST is bad because you couldn't find an auto-generation tool to do your work for you? Because that's hilarious.

Also, you don't seem to have looked terribly hard, because there are a few really powerful tools out there for autogenerating server and client code for REST APIs, as well as mock servers and a whole host of other tooling (See: Swagger, RAML, API Blueprint for starting points).

Re: Problems with RESTful APIs (2015)

#195

Post by nippoo »

richardwhiuk wrote: post #76
int_19h wrote: post #56

Earlier quoted context omitted.

What we really need is a set of verbs that allow to reliably distinguish between these three types of operations: 1. Pure read. 2. Impure (stateful) read. 3. Idempotent write. 4. Any other write. There's no particular reason to separate inserts, updates, deletes etc as part of the protocol - they're all just different kinds of writes, and middleware doesn't derive any benefit from being able to distinguish them. Thus…

Why oh why oh why do you want a stateful read? That will be the beginning of the end for your architecture.

Rate limiting APIs?

Re: Problems with RESTful APIs (2015)

#196

Post by scaryclam »

masklinn wrote: post #111
codr4life wrote: post #31

Earlier quoted context omitted.

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

So… why do you call it REST rather than just HTTP since that's exactly what it is? You're using GET and POST for what they were built for, great, that's just HTTP, why not call it that? > I have full confidence that the authors considered these ideas, not laws. "The authors" considered hyperlinking to be the one core concept of REST, all the rest is just fluff/transport concerns: http://roy.gbiv.com/untangled/2008/re…

I'm leaning more and more in the direction of ditching the term "REST API" and just saying our APIs are Web or HTTP APIs. I'm beginning to think people just say REST API because it looks better on their CV, not because its helpful to other developers who may end up using it.

Re: Problems with RESTful APIs (2015)

#197

Post by [deleted] »

icebraining wrote: post #100
weq wrote: post #91

Earlier quoted context omitted.

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.

[deleted]

Re: Problems with RESTful APIs (2015)

#198

Post by camus2 »

debaserab2 wrote: post #48

Most of the problems described with REST in this article are examples of REST implemented improperly. We've had years to get it right; things like HTTP verb support, debugging, discoverability are all by and large a solved problem. The one point that stands is that it is deeply tied to HTTP, but I consider that to be a positive: a well designed REST API means the message is only about the content of what it's serving…

> Most of the problems described with REST in this article are examples of REST implemented improperly

If so many people get an idea wrong, then there is a problem with that idea.With SOAP or JSON/XML-RPC, there is a normative spec, and your implementation either passes the spec or it doesn't, so something is SOAP or it isn't and it is provable. There is no spec describing what exactly is REST and what isn't. You can't demonstrate something is or isn't REST in a strict fashion.

A dissertation is not a spec, it is a discussion. Roy Fielding never wrote a REST or a HATEOAS spec. which led to you complaining about how people get them wrong. They didn't get anything wrong, they took some of his ideas and rejected the REST because nobody can tell them what is REST and what isn't.

Re: Problems with RESTful APIs (2015)

#199

Post by [deleted] »

alganet wrote: post #54
coldtea wrote: post #24

Earlier quoted context omitted.

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

Ignoring the dissertation is OK. It was designed for people to understand how the web was designed, not as an implementation guide. Ignoring REST is impossible, the web is built on it. - The uniform interface is in every URI (if you use them, you use REST). - The code-on-demand constraint is everywhere (if you use JavaScript, you're using REST). - Hypermedia is everywhere (if you have links on your web page, you're u…

[deleted]

Re: Problems with RESTful APIs (2015)

#200

Post by camus2 »

u801e wrote: post #90
robzhu wrote: post #72

Like other posters have said, the author appears to be pointing out shortcomings with HTTP, not REST. Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints: https://en.wikipedia.org/wiki/Representational_state_transfe... . Anything that meets these constraints is considered "REST". Most of the constraints sound like common…

> Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints: Out of curiosity, do you know of any examples of RESTful APIs that use a protocol other than HTTP (say like IMAP or NNTP)?

He isn't going to provide you an example because there is none meaning full in production. REST uses HTTP because it makes no sense to use it with anything else. REST only makes sense with HTTP. With another socket protocol, there is no need to bother with headers and co.
Post reply on HN