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

51–60 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#51

Post by HelloNurse »

leourbina wrote: post #12

This post follows the general, highly academic/dogmatic, tone that I’ve seen when certain folks talk about REST. Most of the article talks about what _not_ to do, and has very little details on how to actually do it. The idea of having client/server decoupled via a REST api that is itself discoverable, and that allows independent deployment, seems like a great advantage. However, the article lacks even the simplest e…

> However, the article lacks even the simplest example of an api done the “wrong” vs the “right” way.

Unless the design and requirements are unusually complex or extreme, all styles of API and front end work well enough. Any example would have to be lengthy, to provide context for the advantages of "true" ReST architecture, and contrived.

Re: Most RESTful APIs aren't really RESTful

#53

Post by eadmund »

dewey wrote: post #9

Academically it might be correct, but shipping real features will in most cases be more important than hitting some text book definition of correctness.

Sure, you’re right: pragmatics, in practice, are more important than theory.

But you’re assuming that there is a real contradiction between shipping features and RESTful design. I believe that RESTful design can in many cases actually increase feature delivery speed through its decoupling of clients and servers and more deeply due to its operational model.

Re: Most RESTful APIs aren't really RESTful

#54

Post by mort96 »

ewuhic wrote: post #50
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…

[flagged]

I disagree. It's a perfectly fine approach to many kinds of APIs, and people aren't "mediocre" just for using widely accepted words to describe this approach to designing HTTP APIs.

Re: Most RESTful APIs aren't really RESTful

#55

Post by Scarblac »

sublinear wrote: post #18
Scarblac wrote: post #5

UI designers want control over the look of the page in detail. E.g. some actions that can be taken on a resource are a large button and some are hidden in a menu or not rendered in the UI at all. A client application that doesn't have any knowledge about what actions are going to be possible with a resource, instead rendering them dynamically based on the API responses, is going to make them all look the same. So RES…

My experience with "RESTful APIs" rarely has much to do with the UI. Why even have any API if all you care about is the UI? Why not go back to server driven crap like DWR then?

My experience is that SPAs have been the way to make frontends, for the last eight years or so. May be coming to an end now. Anyway, contact with the backend all went through an API.

During that same time, the business also wanted to use the fact that our applications had an API as a selling point - our customers are pretty technical and some of them write scripts against our backends.

Backenders read about API design, they get the idea they should be REST like (as in, JSON, with different HTTP methods for CRUD operations).

And of course we weren't going to have two separate APIs, that we ran our frontends on our API was another selling point (eat your own dog food, proof that the API can do everything our frontend can, etc).

So: the UI runs on a REST API.

I'm hoping that we'll go back to Django templates with a sprinkle of HTMX here and there in the future, but who knows. That will probably be a separate backend that runs in front of this API then...

Re: Most RESTful APIs aren't really RESTful

#56

Post by eadmund »

pbreit wrote: post #8

RESTful APIs are not RESTful because REST is meh. Our APSi includes HATEAOS links and I have never, not once, witnessed their actual use (but they do double the size of response payloads). It’s interesting that Stripe still even uses form-post on requests.

> Our APSi includes HATEAOS links and I have never, not once, witnessed their actual use (but they do double the size of response payloads).

So your payloads look like this:

    {
        "id": 1,
        "href": "http://someplace.invalid/things/1",
        "next-id": 3,
        "next-href": "http://someplace.invalid/things/3",
    }
And rather than just using next-href your clients append next-id to a hardcoded things base URL? That seems like way more work than doing it the REST way.

Re: Most RESTful APIs aren't really RESTful

#57

Post by Scarblac »

TekMol wrote: post #46
buzzy_hacker wrote: post #42

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=3742902

The same would have worked with a POST endpoint. The story url only would have to point to a web page that creates the upvote post request via JS.

That runs into CORS protections though.

CORS is a lot less strict around GET as it is supposed to be safe.

Re: Most RESTful APIs aren't really RESTful

#58

Post by alkonaut »

Similarly, I call Java programs "Object Oriented programs" despite Alan Kays protests that it isn't at all what Object Orientation was described as in early papers.

The sad truth is that it's the less widely used concept that has to shift terminology, if it comes into wide use for something else or a "diluted" subset of the original idea(s). Maybe the true-OO-people have a term for Kay-like OO these days?

I think the idea of saving "REST" to mean the true Fielding style including HATEOAS and everything is probably as futile as trying to reserve OO to not include C++ or Java.

Re: Most RESTful APIs aren't really RESTful

#59

Post by ewuhic »

mort96 wrote: post #54
ewuhic wrote: post #50

Earlier quoted context omitted.

[flagged]

I disagree. It's a perfectly fine approach to many kinds of APIs, and people aren't "mediocre" just for using widely accepted words to describe this approach to designing HTTP APIs.

The point is lost on you though. There are REST APIs (almost none), and there are "REST APIs" - a battle cry of mediocre developers. Now go tell them their restful has nothing to do with rest. And I am now just repeating stuff said in article and in comments here.

Re: Most RESTful APIs aren't really RESTful

#60

Post by lillecarl »

ewuhic wrote: post #50
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…

[flagged]

I met a DevOps guy who didn't know what "dotfiles" are.

However I'd argue people who use the term to describe it the same as everyone else is the smart one, if you want to refer to the "real" one just add "strict" or "real" in front of it.

I don't think we should dismiss people over drifting definitions and lack of "fountational knowledge".

Post reply on HN