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

401–410 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#401

Post by troupo »

ivan_gammel wrote: post #302
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

It’s something else. List of available actions may include other resources, so you cannot express it with pure HTTP, you need a data model for that (HAL is one of possible solutions, but there are others)

With HATEOAS you're supposed to return the list of available actions with the representation of your state.

Neo4j's old REST API was really good about that. See e.g. get node: https://neo4j.com/docs/rest-docs/current/#rest-api-get-node

Re: Most RESTful APIs aren't really RESTful

#402

Post by recursivedoubts »

LegionMammal978 wrote: post #380
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…

At that level, it would be infinitely clearer to say, " There is no such thing as a RESTful API , since the purpose of REST is to connect a system to a human user. There is only such a thing as a RESTful UI based on an underlying protocol (HTML/HTTP). But the implementation of this protocol (the web browser) is secondary to the actual purpose of the system, which is always a UI."

There is such a thing as a RESTful API, and that API must use hypertext, as is clearly laid out in Fielding's dissertation. I don't know what a RESTful UI is, but I do know what a hypertext is, how a server can return a hypertext, how a client can receive that hypertext and present it to a user to select actions from.

Whether or not the API is being consumed by a script client or a browser client doesn't change the RESTful-ness of it, although it does change how useful the aspects of REST (in particular, the uniform interface) will be to that client.

Re: Most RESTful APIs aren't really RESTful

#403

Post by recursivedoubts »

tshaddox wrote: post #351
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.

I also use Google Maps, YouTube, Spotify, and Figma in the same web browser. But surely most of the functionality of those would not be considered HATEOAS.

Yes, very strongly agree. Browsers, through the code-on-demand "optional" constraint on REST, have become so powerful that people have started to build RPC-style applications in them.

Ironic that Fielding's dissertation contained the seed of REST's destruction!

Re: Most RESTful APIs aren't really RESTful

#404

Post by LegionMammal978 »

recursivedoubts wrote: post #402
LegionMammal978 wrote: post #380

Earlier quoted context omitted.

At that level, it would be infinitely clearer to say, " There is no such thing as a RESTful API , since the purpose of REST is to connect a system to a human user. There is only such a thing as a RESTful UI based on an underlying protocol (HTML/HTTP). But the implementation of this protocol (the web browser) is secondary to the actual purpose of the system, which is always a UI."

There is such a thing as a RESTful API, and that API must use hypertext, as is clearly laid out in Fielding's dissertation. I don't know what a RESTful UI is, but I do know what a hypertext is, how a server can return a hypertext, how a client can receive that hypertext and present it to a user to select actions from. Whether or not the API is being consumed by a script client or a browser client doesn't change the R…

> and that API must use hypertext

I'd say that my web browser is not using hypertext. It is merely transforming it so that I can use the resulting hypermedia, and thereby interface with the remote host. That is, my browser isn't the one that decides how to interface with the remote host; I am. The browser implements the hypertext protocol and presents me a user interface to the remote host.

Fielding might have a peculiar idea of what an "API" is, so that a "human + browser" is a programmatic application, but if that's what he says, then I think his ideas are just dumb and I shouldn't bother listening to him.

> Whether or not the API is being consumed by a script client or a browser client doesn't change the RESTful-ness of it

There's no way for a "script client" to use hypertext without implementing a fixed protocol on top of it, which is allegedly not-RESTful. Unless you count a search engine crawler as such a client, I guess, but that's secondary to the purpose of hypertext.

Re: Most RESTful APIs aren't really RESTful

#405

Post by Jach »

SoftTalker wrote: post #314
hombre_fatal wrote: post #174

Earlier quoted context omitted.

It also means they made some effort to use appropriate http verbs instead of GET/POST for everything, and they made an effort to organize their urls into patterns like `/things/:id/child/:child_id`. It was probably an organic response to the complexity of SOAP/WSDL at the time, so people harping on how it's not HATEOAS kinda miss the historical context; people didn't want another WSDL.

> instead of GET/POST for everything Sometimes that's a pragmatic choice too. I've worked with HTTP clients that only supported GET and POST. It's been a while but not that long ago.

Not even just clients, but servers too would block anything not GET/POST/HEAD. And I believe PHP still to this day only has $_GET and $_POST as out of the box superglobals to conveniently get data params. I recall some "REST" APIs would let you use POST for PUT/DELETE requests if you added a special var or header specifying.

Re: Most RESTful APIs aren't really RESTful

#406

Post by turnsout »

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…

  > The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec
Haha yes! Is it even a dev team if they haven't had an overly heated argument about which 4xx code to return for an error state?

Re: Most RESTful APIs aren't really RESTful

#407

Post by 9rx »

meehai wrote: post #193
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…

the last point got me. How can you idiomatically do a read only request with complex filters? For me both PUT and POST are "writable" operations, while "GET" are assumed to be read only. However, if you need to encode the state of the UI (filters or whatnot), it's preferred to use JSON rather than query params (which have length limitations). So ... how does one do it?

"Filters" suggests that you are trying to query. So, QUERY, perhaps? https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...

Or stop worrying and just use POST. The computer isn't going to care.

Re: Most RESTful APIs aren't really RESTful

#408

Post by rafark »

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…

> Why do people feel compelled to even consider it to be a battle?

Because words have specific meanings. There’s a specific expectation when using them. It’s like if someone said “I can’t install this app on my iPhone” but then they have an android phone. They are similar in that they’re both smartphones and overall behave and look similar, but they’re still different.

If you are told an api is restful there’s an expectation of how it will behave.

Re: Most RESTful APIs aren't really RESTful

#409

Post by theamk »

cyberax wrote: post #360
bborud wrote: post #341

Earlier quoted context omitted.

What RPC mechanisms, in your opinion, are the most ergonomic and why? (I have been offering REST’ish and gRPC in software I write for many years now. With the REST’ish api generated from the gRPC APIs. I’m leaning towards dropping REST and only offering gRPC. Mostly because the generated clients are so ugly)

Just use gRPC or ConnectRPC (which is basically gRPC but over regular HTTP). It's simple and rigid. REST is just too "floppy", there are too many ways to do things. You can transfer data as a part of the path, as query parameters, as POST fields (in multiple encodings!), as multipart forms, as streaming data, etc.

Just not in C++ code. gprc has a bajillon dependencies, and upgrades are a major pain. If you have a dedicated build team and they are willing to support this - sure, go ahead and use it.

But if you have multiple targets, or unusual compilers, or don't enjoy working with build systems, stay away from complex stuff. Sure, REST may need some manual scaffolding, but no matter what your target is, there is a very good chance it has JSON and HTTP libs.

Re: Most RESTful APIs aren't really RESTful

#410

Post by rplnt »

cyberax wrote: post #360
bborud wrote: post #341

Earlier quoted context omitted.

What RPC mechanisms, in your opinion, are the most ergonomic and why? (I have been offering REST’ish and gRPC in software I write for many years now. With the REST’ish api generated from the gRPC APIs. I’m leaning towards dropping REST and only offering gRPC. Mostly because the generated clients are so ugly)

Just use gRPC or ConnectRPC (which is basically gRPC but over regular HTTP). It's simple and rigid. REST is just too "floppy", there are too many ways to do things. You can transfer data as a part of the path, as query parameters, as POST fields (in multiple encodings!), as multipart forms, as streaming data, etc.

You can mess up grpc just as much. Errors are a good place to start.
Post reply on HN