Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most RESTful APIs aren't really RESTful

florian-kraemer.net

Post reply on HN
Print view View original

291–300 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#291

Post by lalaithion »

troupo wrote: post #257
tgv wrote: post #159

Earlier quoted context omitted.

Do you care? From my point of view, post, put, delete, update, and patch all do the same. I would argue that if there is a difference, making the distinction in the url instead of the request method makes it easier to search code and log. And what's the correct verb anyway? So that's an argument that there may be too many request methods, but you could also argue there aren't enough. But then standardization becomes…

> From my point of view, post, put, delete, update, and patch all do the same. That's how we got POST-only GraphQL. In HTTP (and hence REST) these verbs have well-defined behaviour , including the very important things like idempotence and caching: https://github.com/for-GET/know-your-http-well/blob/master/m...

Yeah but GET doesn’t allow requests to have bodies (yeah, I know, technically you can but it’s not very useful), and this is a legitimate issue preventing its use in complex APIs.

Re: Most RESTful APIs aren't really RESTful

#292

Post by marcosdumay »

mrweasel wrote: post #112
k2xl wrote: post #102

Earlier quoted context omitted.

This is very true. Over my 15 years of engineering, I have never suffered_that_ much with integrating with an api (assuming it exists). So the lack of "HATEOaS" hasn't even been noticable for me. As long as they get most of the 400 status codes right (specifically 200, 401, 403, 429) I usually have no issuss integrating and don't even notice that they don't have some "discoverable api". As long as I can get the data…

> As long as they get most of the 400 status codes right (specifically 200, 401, 403, 429) A client had build an API that would return 200 on broken requests. We pointed it out and asked if maybe it could return 500, to make monitoring easier. Sure thing, next version "Http 200 - 500", they just wrote 500 in the message body, return remained 200. Some developers just do not understand http.

I just consumed an API where errors were marked with a "success": false field.

The "success" is never true. If it's successful, it's not there. Also, a few endpoints return 500 instead, because of course they do. Oh, and one returns nothing on error and data on success, because, again, of course it does.

Anyway, if you want a clearer symptom that your development stack is shit and has way too much accidental complexity, there isn't any.

Re: Most RESTful APIs aren't really RESTful

#293

Post by mixedbit »

naasking wrote: post #273
mixedbit wrote: post #245

Earlier quoted context omitted.

There are many ideas in the REST paper that are super useful, but the goal of making a generic client working with any API is difficult if not impossible to achieve. Was the client of the service that you worked on fully generic and application independent? It is one thing to be able to change URLs only on the server, without requiring a client code change, and such flexibility is indeed practical benefit that the RE…

> There are many ideas in the REST paper that are super useful, but the goal of making a generic client working with any API is difficult if not impossible to achieve. It's definitely possible to achieve: anywhere that data is missing you present an input prompt, which is exactly what a web browser does. That said, the set of autonomous programs that can do something useful without knowing what they're doing is of co…

> Web browsers do exactly this!

Browser provide generic execution environment, but the client code (JavaScript/HTML/CSS) is not generic. Calendar application and messaging application entry points provide application specific code for implementing calendar or messaging apps functions . I don't think this is what was proposed in the REST paper, otherwise we wouldn't have articles like 'Most RESTful APIs aren't really RESTful'.

Re: Most RESTful APIs aren't really RESTful

#294

Post by rswail »

I love all the comments here that you can't build a proper UX/UI with a "perfect" REST API even though browsers do it all day, every day.

REST includes code-on-demand as part of the style, HTTP allows for that with the "Link" header and HTML via .

Re: Most RESTful APIs aren't really RESTful

#296

Post by cryptonector »

> The core problem it addresses is client-server coupling. There are probably countless projects where a small change in a server’s URI structure required a coordinated (and often painful) deployment of multiple client applications. A HATEOAS-driven approach directly solves this by decoupling the client from the server’s namespace. This addresses the quality of evolvability.

Eh, "a small change in a server’s URI structure" breaks links, so already you're in trouble.

But sure, embedding [local-parts of] URIs in the contents (or headers) exchanged is indeed very useful.

Re: Most RESTful APIs aren't really RESTful

#297

Post by cryptonector »

motorest wrote: post #144
cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

> I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. Why do people feel compelled to even consider it to be a battle? As I see it, the REST concept is useful, but the HATEOAS detail ends up having no practical value and creates more problems than the ones it solves. This is in line with the Richardson maturity model[1], where the apex of REST includes all the…

Defining media types seems right to me, but what ends up happening is that you use swagger instead to define APIs and out the window goes HATEOAS, and part of the reason for this is just that defining media types is not something people do (though they should).

Basically: define a schema for your JSON, use an obvious CRUD mapping to HTTP verbs for all actions, use URI local-parts embedded in the JSON, use standard HTTP status codes, and embed more error detail in the JSON.

Re: Most RESTful APIs aren't really RESTful

#298

Post by marcosdumay »

s_ting765 wrote: post #212
kccqzy wrote: post #171

Earlier quoted context omitted.

It's not just the original REST that usually has no benefits. The industry's reinterpreted version of weak REST also usually has little to no benefits. Who really cares that deleting a resource must necessarily be done with the DELETE HTTP verb rather than simply a POST?

The DELETE verb exists, there's no reason not to use it.

The POST verb exists, there's no reason not to use it to ask a server to delete data.

In fact, there are plenty of reasons not to use DELETE and PUT. Middleboxes managed by incompetent security people block them, they require that developers have a minimum of expertise and don't break the idempotency rule, lots of software stacks simply don't support them (yeah, those stacks are bad, what still doesn't change anything), and the most of the internet just don't use the benefit they provide (because they don't trust the developers behind the server to not break the rules).

Re: Most RESTful APIs aren't really RESTful

#299

Post by Supermancho »

OJFord wrote: post #87
cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

> I can safely assume [...] CRUD actions are mapped to POST/GET/PUT/DELETE Not totally sure about that - I think you need to check what they decided about PUT vs PATCH.

It's always better to use GET/POST exclusively. The verb mapping was theoretical from someone who didn't have to implement. I've long ago caved to the reality of the web's limited support for most of the other verbs.

Re: Most RESTful APIs aren't really RESTful

#300

Post by ivan_gammel »

shadowgovt wrote: post #232
ivan_gammel wrote: post #223

Earlier quoted context omitted.

You have got it wrong. Let's say I build some API with different user roles. Some users can delete an object, others can only read it. The UI knows about the semantics of the operations and logical names of it, so when UI gets the object from server it can simply check, if certain operations are available, instead of encoding the permission checking on the client side. This is the discoverability. It does not imply g…

How does the UI check if certain operations are available?

It’s literally in server response:

   {
    … resource model
    _links: {
       “delete” : { “href” : “.” }
    }
In this example you receive list of permitted operations embedded in the resource model. href=. means you can perform this operation on resource self link.
Post reply on HN