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

461–470 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#461

Post by nchmy »

wstrange wrote: post #366
nchmy wrote: post #190

Earlier quoted context omitted.

How are web browsers hypothetical? We're using one with rest/hateoas/hypermedia right now ... You don't seem to have even the slightest idea of what you're talking about here. Again, I suggest checking out the htmx essays and their hypermedia.systems book

It should be obvious that the thing doing the interpretation and navigation is a human, not an automated system.

i dont have any clue why people keep bringing up automated systems in this discussion. its not relevant. Hypermedia - and REST - is for humans

If you need an http json api for bots to consume, go for it. They are not mutually exclusive.

Re: Most RESTful APIs aren't really RESTful

#462

Post by Aeolun »

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…

Having 12 different independent copies means nobody on your 30 people multi-region team is blocked.

Re: Most RESTful APIs aren't really RESTful

#463

Post by no_circuit »

thaumasiotes wrote: post #110
Traubenfuchs wrote: post #68

REST(ful) API issues can all be resolved with one addition: Adding actions to it! POST api/registration / api/signup? All of this sucks. Posting or putting on api/user? Also doesn‘t feel right. POST to api/user:signup Boom! Full REST for entities + actions with custom requests and responses for actions! How do I make a restful filter call? GET request params are not enough… You POST to api/user:search, boom! (I prefe…

What is the problem with posting to /user/signup that posting to /user:signup solves?

The system won't be able remember why the user was created unless the content of the post includes data saying it was a signup. That's important for any type of reporting like telemetry and billing.

So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. Or that since the user resource doesn't exist yet perhaps one can't call a method on it, so it really should be /users:signup (on the users collection, like /users:add).

Provided one isn't opposed to adopting what was bike-shedded elsewhere, there is a fairly well specified way of doing something RESTful, here is a link to its custom methods page: https://google.aip.dev/136. Its approach would be to add information about signup in a request to the post to /users: https://google.aip.dev/133. More or less it describes a way to be RESTful with HTTP/1.1+JSON or gRPC.

Re: Most RESTful APIs aren't really RESTful

#464

Post by OJFord »

Xenoamorphous wrote: post #137
OJFord wrote: post #87

Earlier quoted context omitted.

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

Isn't that fairly straightforward? PUT for full updates and PATCH for partial ones. Does anybody do anything different?

That's straightforwardly 'correct' and Fielding's thesis, yes. Yes people do things differently!

Re: Most RESTful APIs aren't really RESTful

#465

Post by OJFord »

CSMastermind wrote: post #244
Xenoamorphous wrote: post #137

Earlier quoted context omitted.

Isn't that fairly straightforward? PUT for full updates and PATCH for partial ones. Does anybody do anything different?

Lots of people make PUTs that work like PATCHes and it drives me crazy. Same with people who use POST to retrieve information.

  POST /gql
  "Get thing"
  ...
  200
  "Permission denied to get thing"
Hate it.

Re: Most RESTful APIs aren't really RESTful

#466

Post by thaumasiotes »

no_circuit wrote: post #463
thaumasiotes wrote: post #110

Earlier quoted context omitted.

What is the problem with posting to /user/signup that posting to /user:signup solves?

The system won't be able remember why the user was created unless the content of the post includes data saying it was a signup. That's important for any type of reporting like telemetry and billing. So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. Or that since the user resource doesn't exist yet perhaps one can't call a method on it, so it really should be /users:si…

> So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body.

But that's not a difference between /user/signup and /user:signup .

Re: Most RESTful APIs aren't really RESTful

#467

Post by stephenlf »

> A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.]

What the heck does this mean? Does it mean that my API isn’t REST if it can’t interpret “http://example.com/path/to/resource” in the same way it interprets “COM::path.to.resource”? Is it saying my API should support HTTP, FTP, SMB, and ODBC all the same? What am I missing?

Re: Most RESTful APIs aren't really RESTful

#468

Post by nosefrog »

cyberax wrote: post #448
paulddraper wrote: post #435

Earlier quoted context omitted.

The critical problem with gRPC is that it uses protocol buffers. Which are...terrible. Example: structured schema, but no way to require fields.

With Protobuf this is a conscious decision to avoid back-compat issues. I'm not sure if I like it.

Infra teams like it, app devs don't like it.

Re: Most RESTful APIs aren't really RESTful

#469

Post by no_circuit »

thaumasiotes wrote: post #466
no_circuit wrote: post #463

Earlier quoted context omitted.

The system won't be able remember why the user was created unless the content of the post includes data saying it was a signup. That's important for any type of reporting like telemetry and billing. So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. Or that since the user resource doesn't exist yet perhaps one can't call a method on it, so it really should be /users:si…

> So then one gets to bike-shed if "signup" it is in the request path, query parameters, or the body. But that's not a difference between /user/signup and /user:signup .

That's correct, the example you are giving represents bike-shedding among request path variations.

I assumed most readers of my comment would get that the idea that /users/signup is ambiguous whether or not that is supposed to be another resource, while /users:signup is less so.

Re: Most RESTful APIs aren't really RESTful

#470

Post by Joker_vD »

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

I really wish people just used 200 status code and put encoded errors in the payloads themselves instead of trying to fuse the transport layer's (which HTTP serves as, in this case) concerns with the application's concerns. Seriously, HTTP does not mandate that e.g. "HTTP/1.1 503 Ooops\r\n\r\n" should be stuffed into the TCP's RST packet, or into whatever TLS uses to signal severe errors, for bloody obvious reasons: it doesn't belong there.

Like, when you get a 403/404 error, it's very bloody difficult to tell apart the "the reverse proxy before the server is misconfigured and somebody forgot to expose the endpoint" and "the server executed your request to look up an item perfectly fine: the DB is functional, and the item you asked for is not in there" scenarios. And yeah, of course I could (and should) look at and try to parse the response's body but why? This "let's split off the 'error code' part of the message from the message and stuff it somewhere into the metadata, that'll be fine, those never get messed up or used for anything else, so no chance of confusion" approach just complicates things for everyone for no benefit whatsoever.

Post reply on HN