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

181–190 of 224 posts

Re: Problems with RESTful APIs (2015)

#181

Post by fnord123 »

icebraining wrote: post #173
fnord123 wrote: post #163

Earlier quoted context omitted.

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

>Imagine if we had to write a new browser plugin for each new site we published

You mean like Electron applications? :P

But seriously, I don't know what kind of clients you want to use, but if I want to store data on an object store, for example, I know what the verbs are. And if a new one is added, then at some point I need to change something on the client side to factor that in. Unless the server is also serving the UI as they do with web pages.

If I'm using something like $AccountingProgram and my bank puts in a new possible action like "donate" to let me easily donate to charities which will return important information like deductions and the relevant fields, etc., then how might my accounting become aware of this new concept? .

Maybe I'm too troglodyte to see it. My engineering senses are tingling with excitement that it would be cool that it automatically gets through to the client (without also being open to click/UI hijacking from shitheads) but I just don't see how it can happen.

Re: Problems with RESTful APIs (2015)

#182

Post by Pigo »

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…

I was excited when I first came across a RESTful solution I could use because I was living in a world where WCF was still considered groundbreakingly simple, and there was still asmx hanging around that I was avoiding like the plague. If there's a better model out there, and an implementation I can do hands-on research with, I'm always open to new ideas. But I am usually turned off by developers who feel the need to dump on what everyone else is doing instead of just proposing their new solution enthusiastically. Just like how I enjoy hearing how other people propose to use RESTful API's semantically, but not if they're going to spend half the time just ripping on how I've been doing it successfully for years.

Re: Problems with RESTful APIs (2015)

#183

Post by stymaar »

masklinn wrote: post #150
stymaar wrote: post #138

Earlier quoted context omitted.

> If it's independent of HATEOAS what is in REST? Using GET/POST/PUT/DELETE with a defined semantic, the confidence that GET is idempotent, and the proper use of HTTP status codes. Back in 2005, it was really common to have only GET routes even for update of deletion, or worst: to have a single url: http://example.org/action which concentrated all the API surface, different behavior being triggered by the type of the…

> Using GET/POST/PUT/DELETE with a defined semantic, the confidence that GET is idempotent, and the proper use of HTTP status codes. That's literally got nothing to do with REST though, that's straight out of RFC 7231 (sections 4 "request methods" and 6 "response status codes") and the IANA HTTP Method Registry.

You're right and wrong at the same time:

- Technically REST and HTTP are two different things, I totally agree with you.

- Historically, before REST became popular, people where doing complete nonsense on top of HTTP, with no respect of the spec whatsoever (see my comment above). This madness was stopped because of REST ! It's only when REST gained in popularity that people started to learn HTTP, and since then people developed a lot of semantically valid HTTP interface and called them REST API.

To sum up my previous points : REST as imagined by Roy Fielding never caught, and the word REST is now almost unanimously used to describe «HTTP-compliant API». May HATEOAS rest in peace :)

Re: Problems with RESTful APIs (2015)

#184

Post by jandrese »

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.

You mean like a cursor in a database?

Re: Problems with RESTful APIs (2015)

#185

Post by rantanplan »

naasking wrote: post #169
rantanplan wrote: post #154

Earlier quoted context omitted.

You're just supporting my argument and weakening REST's case. I can do you one better. If you managed to reduce everything down to GET and POST here's an idea; just use POST for everything. Boom. You just re-invented SOAP.

> You're just supporting my argument and weakening REST's case. How? Perhaps you should actually elaborate your argument. REST doesn't depend on the use of verbs, it's an architecture that elaborates the requirements for object designation (URLs), object lifetimes (statelessness) and hypermedia-driven service discovery (HATEOAS). Only GET and POST in HTTP are required to fulfill these requirements. If there's actuall…

It's not a false equivalency. Books have been written about it and describe how you defeat REST by doing what you describe.

When you encapsulate most of your operations under POST you basically create your arbitrary protocol. No assumptions can be made about your service. You can make your own assumptions about your own service, but the others can't.

> That would be a fine protocol, and totally REST compatible. What's the problem exactly?

The problem would be that it wouldn't be REST compatible. You should clearly read a few books on the subject. Friendly advice, not a snarky comment.

REST already has idempotent mutating operations, like PUT and DELETE. It's not just GET that's idempotent. So clearly the problem is that you redefine your own protocol, with your own semantics, even though we already have plenty of standardized methods/response codes.

> If there's actually something wrong with that, then lay it out.

You have obviously missed a ton of bibliography on the subject. Before reading random blog posts from random people who have their arbitrary assumptions about what REST is, I'd suggest reading a few books on the subject.

Honestly sorry if I sound snarky, but after 10 years on working with such APIs, and after reading countless books on the subject, it never ceases to amaze me how people still think that GET and POST are enough. But I don't blame you, but the browsers who basically broke the protocol by just using those 2.

Re: Problems with RESTful APIs (2015)

#186

Post by gwbas1c »

foota wrote: post #45
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…

I've heard this argument often, what behavior are people referring to when they talk about these advantages? Is this just referring to using semantically correct HTTP status codes for things like caching, or is there more to it that I'm missing? edit: And also, and perhaps most important, what about REST makes it easier to take advantage of the transport layer's advantages? edit 2: This article has answered some of m…

You can use tools like Fiddler, or browser's built-in HTTP viewers, to observe interactions between your application and the server.

At a minimum, error codes and verbs help these tools highlight different behavior and problems. A 4xx class error, which usually means that your client-side application did something wrong, or that your user did something wrong, is very different than a 5xx class error that means that something really screwed up in the server.

Thus, the response codes make it very easy to use a 3rd party tool to diagnose malfunctions, even when the 3rd party tool doesn't know much about the application.

Likewise, at a minimum, a GET request is a read and doesn't change state. This is also useful when using a 3rd party tool to diagnose an application that runs over HTTP.

I do think that the article points out just how confusing proper REST can be. The semantics don't always match what the API is actually doing, either. Perhaps it's best to just limit oneself to the GET and POST verbs, 200, a few 4xx error codes, and 500. Perhaps it's also best to assume that rest semantics are for diagnostics and not for application level control?

Re: Problems with RESTful APIs (2015)

#187

Post by SEJeff »

Mikhail_Edoshin wrote: post #165
SEJeff wrote: post #79

Earlier quoted context omitted.

Or (for REST apis that might need concurrent updates of the same model) the most awesome "esoteric" verb, PATCH

Look into WebDAV and you'll find plenty :) LOCK, UNLOCK, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH. And also REPORT, SEARCH, and various version-control operations.

Oh sure, but the context is REST apis, not WebDAV :)

PATCH allows two users to update different fields on the same resource at the same time with no conflicts. Otherwise, they'd use PUT and the last update would win unless they use something (client-side) such as compare and set.

Re: Problems with RESTful APIs (2015)

#188

Post by apo »

> REST became popular when it was detailed and promoted by Roy Fielding as part of his doctoral dissertation entitled Architectural Styles and the Design of Network-based Software Architectures in the year 2000. Roy is well known for his contributions to development of the web, especially the HTTP specification.

So far so good.

> Roy advocated using the request methods he helped define in the HTTP standards to impart meaning to HTTP requests.

Not even close.

REST may be one of the most misunderstood ideas in all of computer science. As described in Fielding's dissertation, REST is a software architectural style whose main idea is that hypertext drives state changes, aka Hypermedia as the Engine of Application State (HATEOAS). Fielding leaves the transport protocol as an implementation detail.

In other words, an automated agent (API consumer) should interact with an API in the same way that a human interacts with a Web site. User browses to well-known URL. Page displays content with links. User clicks on a link. And so on.

A human doesn't need to read documentation on using any particular website any more than an automated agent should need to carry service-specific instructions on using an API. Media types and hyperlinks do all the heavy lifting.

The stuff about structured URLs and response codes came later, was created by others, and has almost nothing to do with REST's central idea. It's a different architectural style altogether.

From Fielding himself:

> I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

Re: Problems with RESTful APIs (2015)

#189

Post by naasking »

rantanplan wrote: post #185
naasking wrote: post #169

Earlier quoted context omitted.

> You're just supporting my argument and weakening REST's case. How? Perhaps you should actually elaborate your argument. REST doesn't depend on the use of verbs, it's an architecture that elaborates the requirements for object designation (URLs), object lifetimes (statelessness) and hypermedia-driven service discovery (HATEOAS). Only GET and POST in HTTP are required to fulfill these requirements. If there's actuall…

It's not a false equivalency. Books have been written about it and describe how you defeat REST by doing what you describe. When you encapsulate most of your operations under POST you basically create your arbitrary protocol. No assumptions can be made about your service. You can make your own assumptions about your own service, but the others can't. > That would be a fine protocol, and totally REST compatible. What'…

> When you encapsulate most of your operations under POST you basically create your arbitrary protocol. No assumptions can be made about your service.

And you shouldn't make such assumptions, you should just use the input parameters exposed in hypermedia which you obtained from a public service entry point. It's called encapsulation and that's REST. Again, what's the problem? All I hear is complaining that REST doesn't work the way other architectures work. Big surprise.

Certainly REST's HATEOAS can sometimes make a service less efficient as compared to some alternatives (so it can preserve encapsulation and support upgrade), but that's not the claim you're making. You're claiming some kind of insufficiency.

> The problem would be that it wouldn't be REST compatible. You should clearly read a few books on the subject. Friendly advice, not a snarky comment.

I've read Fielding's thesis, thanks. I understand REST perfectly well.

> REST already has idempotent mutating operations, like PUT and DELETE. It's not just GET that's idempotent.

So what? PUT and DELETE don't have the necessary semantics. GET representation, apply operation listed in representation via POST. What more do you need?

> Honestly sorry if I sound snarky, but after 10 years on working with such APIs, and after reading countless books on the subject, it never ceases to amaze me how people still think that GET and POST are enough

You still haven't pointed out a single reason why GET+POST are not enough or how they "break REST". I'm not asking for "a ton of bibliography", I'm asking for a single example. An existence proof that my claim is false. It should be trivial if this shit ton of bibliography exists.

Frankly, most of this vaunted "bibliography" since Fielding's thesis has been non-REST crap. It's amazing how easily people can misunderstand a 150 page thesis.

Re: Problems with RESTful APIs (2015)

#190

Post by pc86 »

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…

PUT and DELETE are just HTTP verbs and don't directly have anything to do with REST. You can support all verbs and have a garbage REST implementation, and (while obviously more difficult) have a great REST implementation for a handful of verbs.
Post reply on HN