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

331–340 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#331

Post by bokchoi »

marcosdumay wrote: post #259
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 really hate my conclusions here, but from a limited freedom point of view, if all of that is going to happen... > The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec So we should better start with a standard scaffolding for the replies so we can encode the errors and forget about status codes. So the only thing generating an error status is unhandled excepti…

The world would be lovely if we could have standard error, listing responses, and a common query syntax.

I haven't done REST apis in a while, but I came across this recently for standardizing the error response: https://www.rfc-editor.org/rfc/rfc9457.html

Re: Most RESTful APIs aren't really RESTful

#332

Post by singpolyma3 »

PaulHoule wrote: post #325
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…

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…

I mean, HTTP is an RPC protocol. It has methods and arguments and return types.

What I object to about eg xml-rpc is that it layers a second RPC protocol over HTTP so now I have two of them...

Re: Most RESTful APIs aren't really RESTful

#333

Post by yndoendo »

majkinetor wrote: post #327
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…

Amen. Particularly ISO8601.

Always thought that a standard like ISO8601 which always stores the date and time in UTC but appends the local time zone would beneficial.

Re: Most RESTful APIs aren't really RESTful

#334

Post by recursivedoubts »

ehutch79 wrote: post #282
recursivedoubts wrote: post #255

Earlier quoted context omitted.

Yes. You used such an api to post your reply. And I am using it as well, via the affordances presented by the mobile safari hypermedia client program. Quite an amazing system!

No. I was served HTML. not a json respoise that the browser discovered how to display.

Yes. Exactly.

Re: Most RESTful APIs aren't really RESTful

#335

Post by ivan_gammel »

shadowgovt wrote: post #318
ivan_gammel wrote: post #300

Earlier quoted context omitted.

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.

Oh, interesting. So rather than the UI computing what operations should be allowed currently by, say, knowing the user's current role and having rules baked into it about the relationship between role and UI widgets, the UI can compute what motive should be in or simply off of explicit statements or capability from the server. I can see some meat on these bones. The counterpoint is that the protocol is now chattier t…

I’d suggest that bandwidth optimization should happen when it becomes critical and control presence of hypermedia controls via feature flag or header. This way frontend becomes simpler, so FE dev speed and quality improves, but backend becomes more complex. The main problem here is that most backend frameworks are supporting RMM level 2 and hypermedia controls require different architecture to make server code less verbose. Unfortunately REST wasn’t understood well, so full support of it wasn’t in focus of open source community.

Re: Most RESTful APIs aren't really RESTful

#336

Post by recursivedoubts »

nlawalker wrote: post #265
recursivedoubts wrote: post #224

Earlier quoted context omitted.

I agree that's a common understanding of things, but I don't think that it's 100% accurate. I think that a web browser is a client program, consuming a RESTful application programming interface in the manner that RESTful APIs are designed to be consumed, and presenting the result to a human to choose actions. I think if you restrict the notion of client to "automated programs that do not have a human driving them" th…

If you allow the notion of client to include "web browser driven by humans", then what is it about Fielding's dissertation that is considered so important and original in the first place? Sure it's formal and creates some new and precise terminology, but the concept of browsing was already well established when he wrote it.

It formalized the network architecture of distributed hypermedia systems and described interesting characteristics and tradeoffs of that approach. Whether or not it did a GOOD job of that for the layman I will leave to you, only noting the confusion around the topic found, ironically, across the internet.

Re: Most RESTful APIs aren't really RESTful

#337

Post by recursivedoubts »

dwaltrip wrote: post #310
recursivedoubts wrote: post #168

Earlier quoted context omitted.

Yes. You used it to enter this comment. I am using it to enter this reply. The magical client that can make use of an auto-discoverable API is called a "web browser", which you are using right this moment, as we speak.

Wait what? So everything is already HATEOAS? I thought the “problem” was that no one was building proper restful / HATEOAS APIs. It can’t go both ways.

The web, in traditional HTML-based responses, uses HATEOAS, almost by definition. JSON APIs rarely do, and when they do it's largely pointless.

https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

Re: Most RESTful APIs aren't really RESTful

#338

Post by ivan_gammel »

guru4consulting wrote: post #303
ivan_gammel wrote: post #187

Earlier quoted context omitted.

>the HATEOAS detail ends up having no practical value and creates more problems than the ones it solves. Many server-rendered websites support REST by design: a web page with links and forms is the state transferred to client. Even in SPAs, HATEOAS APIs are great for shifting business logic and security to server, where it belongs. I have built plenty of them, it does require certain mindset, but it does make many th…

complexity

Backend only and verbosity would be more correct description.

Re: Most RESTful APIs aren't really RESTful

#339

Post by beders »

I always urge software architects (are they still around?) and senior engineers in charge of APIs to think very carefully about the consumers of the API.

If the only consumer is your own UI, you should use a much more integrated RPC style that helps you be fast. Forget about OpenAPI etc: Use a tool or library that makes it dead simple to provide data the UI needs.

If you have a consumer outside your organization: a RESTish API it is.

If your consumer is supposed to be generic and can "discover" your API, RESTful is the way to go.

But no one writes generic ones anymore. We already have the ultimate one: the browser.

Post reply on HN