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

391–400 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#391

Post by foobarian »

agumonkey wrote: post #386
PaulHoule wrote: post #325

Earlier quoted context omitted.

Fielding won the war precisely because he was intellectually incoherent and mostly wrong. It's the "worse is better" of the 21st century. RPC systems were notoriously unergonomic and at best marginally successful. See Sun RPC, RMI, DCOM, CORBA, XML-RPC, SOAP, Protocol Buffers, etc. People say it is not RPC but all the time we write some function in Javascript like const getItem = async (itemId) => { ... } which does…

When I realized that I was calling openapi-generator to create client side call stubs on non-small service oriented project, I started missing J2EE EJB. And it takes a lot to miss EJB. I'd like to ask seasoned devs and engineers here. Is it the normal industry-wide blind spot where people still crave for and are happy creating 12 different description of the same things across remote, client, unit tests, e2e tests, o…

I've seen some systems with a lot of pieces where teams have attempted to avoid repetition and arranged to use a single source of schema truth to generate various other parts automatically, and it was generally more brittle and harder to maintain due to different parts of the pipeline owned by different teams, and operated on different schedules. Furthermore it became hard to onboard to these environments and figure out how to make changes and deploy them safely. Sometimes the repetition is really the lesser evil.

Re: Most RESTful APIs aren't really RESTful

#393

Post by 9dev »

notpushkin wrote: post #261
troupo wrote: post #246

Earlier quoted context omitted.

OPTIONS https://datatracker.ietf.org/doc/html/rfc2616 More links here: https://news.ycombinator.com/item?id=44510745

Or probably just an Allow header on a response to another query (e.g. when fetching an object, server could respond with an Allow: GET, PUT, DELETE if the user has read-write access and Allow: GET if it’s read-only).

That’s a neat idea actually, I think I’ll need to read up on the semantics of Allow again…. There is no reason you couldn’t just include it with arbitrary responses, no?

Re: Most RESTful APIs aren't really RESTful

#394

Post by bornfreddy »

agumonkey wrote: post #386
PaulHoule wrote: post #325

Earlier quoted context omitted.

Fielding won the war precisely because he was intellectually incoherent and mostly wrong. It's the "worse is better" of the 21st century. RPC systems were notoriously unergonomic and at best marginally successful. See Sun RPC, RMI, DCOM, CORBA, XML-RPC, SOAP, Protocol Buffers, etc. People say it is not RPC but all the time we write some function in Javascript like const getItem = async (itemId) => { ... } which does…

When I realized that I was calling openapi-generator to create client side call stubs on non-small service oriented project, I started missing J2EE EJB. And it takes a lot to miss EJB. I'd like to ask seasoned devs and engineers here. Is it the normal industry-wide blind spot where people still crave for and are happy creating 12 different description of the same things across remote, client, unit tests, e2e tests, o…

It's not that we like it, it's just that most other solutions are so complex and difficult to maintain that repetition is really not that bad a thing.

I was however impressed with FastAPI, a python framework which brought together API implementation, data types and generating swagger specs in a very nice package. I still had to take care of integration tests by myself, but with pytest that's easy.

So there are some solutions that help avoid schema duplication.

Re: Most RESTful APIs aren't really RESTful

#395

Post by BrenBarn »

> Furthermore, the initial cognitive overhead of building a truly hypermedia-driven client was perceived as a significant barrier. It felt easier for a developer to read documentation and hardcode a URI template like /users/{id}/orders than to write a client that could dynamically parse a _links section and discover the “orders” URI at runtime.

It "was perceived as" a barrier because it is a barrier. It "felt easier" because it is easier. The by-the-book REST principles aren't a good cost-benefit tradeoff for common cases.

It is like saying that your microwave should just have one button that you press to display a menu of "set timer", "cook", "defrost", etc., and then one other button you use to select from the menu, and then when you choose one it shows another menu of what power level and then another for what time, etc. It's more cumbersome than just having some built-in buttons and learning what they do.

I actually own a device that works in that one-button way. It's an OBD engine code reader. It only has two buttons, basically "next" and "select" and everything is menus. Even for a use case that basically only has two operations ("read the codes" and "clear a code"), it is noticeably cumbersome.

Also, the fact that people still suggest it's indispensable to read Fielding's dissertation is the kind of thing that should give everyone pause. If the ideas are good there should be many alternative statements for general audiences or different perspectives. No one says that you don't truly understand physics unless you read Newton's Principia.

Re: Most RESTful APIs aren't really RESTful

#396

Post by bornfreddy »

PaulHoule wrote: post #358
mardifoufs wrote: post #346

Earlier quoted context omitted.

I'm not super familiar with SOAP and CORBA, but how is SOAP any more coherent than a "RESTful" API? It's basically just a bag of messages. I guess it involves a schema, but that's not more coherent imo, since you just end up with specifics for every endpoint anyways. CORBA is less "incoherent", but I'm not sure that's actually helpful, since it's still a huge mess. You can most likely become a lot more proficient wit…

SOAP, CORBA and such have a theory for everything (say authentication) It's hard to learn that theory, you have to learn a lot of it to be able to accomplish anything at all, you have to deal with build and tooling issues, but if you look closely there will be all sorts of WTFs. Developers of standards like that are always implementing things like distributed garbage collection and distributed transactions which are…

Agree with most of what you said, except about HTTP Basic auth. That is used everywhere - take a look at any random API and there is roughly 90% chance that this is the authentication mechanism used. For backends which serve a single frontend maybe not so much, but still in places.

Re: Most RESTful APIs aren't really RESTful

#397

Post by 9dev »

foobarian wrote: post #389
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've been doing web development for more than a decade and I still can't figure out what REST actually means, it's more of a vibe. When I think about some of the RESTy things we do like return part of the response as different HTTP codes, they don't really add that much value vs. keeping things on the same layer. So maybe the biggest value add so far is JSON, which thanks to its limited nature prevents complication,…

> I've been doing web development for more than a decade and I still can't figure out what REST actually means, it's more of a vibe.

While I generally agree that REST isn’t really useful outside of academic thought experiments: I’ve been in this about as long as you are, and it really isn’t hard. Try reading Fieldings paper once; the ideas are sound and easy to understand, it’s just with a different vision of the internet than the one we ended up creating.

Re: Most RESTful APIs aren't really RESTful

#398

Post by csb6 »

physicles wrote: post #216
mschaef wrote: post #177

> 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. Not sure I agree with this. All it does is…

This is what I don’t understand either. /user/123/orders How is this fundamentally different than requesting /user/123 and assuming there’s a link called “orders” in the response body?

With an HTML body the link will be displayed as content and so will be directly clickable. But if the body is JSON then the client has to somehow generate a UI for the user, which requires some kind of interpretation of the data, so I don’t understand that case.

Re: Most RESTful APIs aren't really RESTful

#399

Post by troupo »

tgv wrote: post #313
troupo wrote: post #257

Earlier quoted context omitted.

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

There's no point in idempotency for operations that change the state. DELETE is supposed to be idempotent, but it can only be if you limit yourself to deletion by unique, non-repeating id. Should you do something like delete by email or product, you have to use another operation, which then obviously will be POST anyway. And there's no way to "cache" a delete operation. It's just absurd to mention idempotency when th…

> There's no point in idempotency for operations that change the state.

Of course there is

> DELETE is supposed to be idempotent, but it can only be if you limit yourself to deletion by unique, non-repeating id

Which is most operations

> Should you do something like delete by email or product, you have to use another operation,

Erm.... No, you don't?

> which then obviously will be POST anyway. And there's no way to "cache" a delete operation.

Why would you want to cache a delete operation?

Re: Most RESTful APIs aren't really RESTful

#400

Post by troupo »

troupo wrote: post #379
andoando wrote: post #359

Earlier quoted context omitted.

The defined behaviors are not so well defined for more complex APIs. You may have an API for example that updates one object and inserts another one, or even deletes an old resource and inserts a new one The verbs are only very clear for very simple CRUD operations. There is a lot of nuance otherwise that you need documentation for and having to deal with these verbs both as the developer or user of an API is a nuisa…

> The defined behaviors are not so well defined for more complex APIs. They are. Your APIs can always be defined as a combination of "safe, idempotent, cacheable"

I've had situations when I wanted a GET with a body :)
Post reply on HN