5 ms·

This article is largely bollocks. 1) Almost every gripe in it refers to bad implementations, not bad specs. 2) It doesn't even mention HATEOAS. I'm no fan, bu

by abraae 10y ago

This article is largely bollocks. 1) Almost every gripe in it refers to bad implementations, not bad specs. 2) It doesn't even mention HATEOAS. I'm no fan, but usually arguments about whether your API is REST or not revolve around how/whether you've done HATEOAS. 3) The rest of it is pulp tech writing that sounds like it was vomited out to meet some kind of publishing deadline. Case in point: > Consider, for example, when we might use the 200 OK response code. Should we use it to indicate the successful update of a record, or should we use 201 Created? Here's a clue - read the spec! (SPOILER ALERT: the word "Created" is the giveaway). To quote: 200 OK The request has succeeded. The information returned with the response is dependent on the method used in the request, for example: <snip> 201 Created The request has been fulfilled and resulted in a new resource being created.

mcguire 10y ago
"2) It doesn't even mention HATEOAS. I'm no fan, but usually arguments about whether your API is REST or not revolve around how/whether you've done HATEOAS." You know that. I know that. But all the comments down to this point in the discussion have been over whether GET, PUT, POST, etc., are necessary or sufficient.
- halostatue 10y ago
  …and having implemented HATEOAS in a service (via json+hal), we’re moving far away (GraphQL) because of versioning, payload weight, and lack of flexibility. I’m sure there are things we could have done better, but the reality is that our clients need things that work differently than a “proper” REST/HATEOAS service. We tried. We failed (insomuch as delivering a working service is failure, but we know it can’t grow the way we want it to grow because the payload weight is far too big). I’m not sure if it was us, or the fact that REST can’t map to everything we want it to be (it can’t, see the attempts to model actions performed to objects like IIRC fishworks did), but we are moving on.
  - icebraining 10y ago
    Like any other architectural model, REST is good for some things, not for others. Versioning and payload weight seem like weird problems to have, though. Seems like JSON might have been a poor encoding for your use case. By the way, do you have a link to that work by fishworks?
    - halostatue 10y ago
      Any sufficiently complex data model will run into an issue where you need a mechanism to selectively render resources differently for different purposes. Putting new routes in place is a heavyweight way of doing this, and query-parameter mechanisms is a real pain. GraphQL started because RESTful APIs at FaceBook were causing great pain for their mobile clients (multiple round trips for data, full data sets, versioning issues on server and client). We experienced the same problem for similar (but smaller) datasets. I did a quick look for the fishworks commentary, but I can’t find the discussion (this was from before the Borgacle consumption of Sun) about how much of a mismatch it was to implement VM controls through a REST interface. Is it legit to POST /vm/:id/restart or should it be a PATCH /vm/:id with a payload of { "action": "restart" }? Or… Many advocates of a particular programming style (OO, REST, TDD are some of the more vocal, but FP advocates are right in there, too) seem to adopt the view that it is appropriate for everything. There’s definitely some impedance mismatch if you try to be REST “pure“ between that and the real world, the same as there will be if you go “pure“ for OO or FP for the same sort of things, but there will be different impedance mismatches. I really tried with HATEOAS, because it makes sense, but the overhead has turned out to outweigh the costs for everything we’ve needed.
weq 10y ago
Spoiler alert, if the majority of implementions are "bad", or dont mention HATEOAS then the article is totally justified. REST will live on in memory, as an idea of a utpoia, just not in implementation.
- icebraining 10y ago
  Nope, the majority of implementations are just fine, and follow HATEOAS pretty closely: they're called "websites". You're using one of them right now.
  - deleted 10y ago
    [deleted]
k__ 10y ago
I thought REST didn't define much so basically every API can be REST conform. Just because HATEOAS makes REST APIs better, doesn't mean those without the use of it aren't REST. Even SOAP can be REST conform. Anyway, I guess with the rise of GraphQL, which is more strict (at least in its definition) REST will go away and we will have better dev life's.
- icebraining 10y ago
  I thought REST didn't define much It does, it's just at a different level. REST is not a protocol, it's a set of architectural constraints, but it's well defined. Only one of the constraints (code-on-demand) is optional. HATEOAS isn't, since you need it to achieve the Uniform Interface that allows you to decouple the clients from the services.
deleted 10y ago
[deleted]

by abraae 10y ago

mcguire 10y ago

"2) It doesn't even mention HATEOAS. I'm no fan, but usually arguments about whether your API is REST or not revolve around how/whether you've done HATEOAS." You know that. I know that. But all the comments down to this point in the discussion have been over whether GET, PUT, POST, etc., are necessary or sufficient.

halostatue 10y ago
…and having implemented HATEOAS in a service (via json+hal), we’re moving far away (GraphQL) because of versioning, payload weight, and lack of flexibility. I’m sure there are things we could have done better, but the reality is that our clients need things that work differently than a “proper” REST/HATEOAS service. We tried. We failed (insomuch as delivering a working service is failure, but we know it can’t grow the way we want it to grow because the payload weight is far too big). I’m not sure if it was us, or the fact that REST can’t map to everything we want it to be (it can’t, see the attempts to model actions performed to objects like IIRC fishworks did), but we are moving on.
- icebraining 10y ago
  Like any other architectural model, REST is good for some things, not for others. Versioning and payload weight seem like weird problems to have, though. Seems like JSON might have been a poor encoding for your use case. By the way, do you have a link to that work by fishworks?
  - halostatue 10y ago
    Any sufficiently complex data model will run into an issue where you need a mechanism to selectively render resources differently for different purposes. Putting new routes in place is a heavyweight way of doing this, and query-parameter mechanisms is a real pain. GraphQL started because RESTful APIs at FaceBook were causing great pain for their mobile clients (multiple round trips for data, full data sets, versioning issues on server and client). We experienced the same problem for similar (but smaller) datasets. I did a quick look for the fishworks commentary, but I can’t find the discussion (this was from before the Borgacle consumption of Sun) about how much of a mismatch it was to implement VM controls through a REST interface. Is it legit to POST /vm/:id/restart or should it be a PATCH /vm/:id with a payload of { "action": "restart" }? Or… Many advocates of a particular programming style (OO, REST, TDD are some of the more vocal, but FP advocates are right in there, too) seem to adopt the view that it is appropriate for everything. There’s definitely some impedance mismatch if you try to be REST “pure“ between that and the real world, the same as there will be if you go “pure“ for OO or FP for the same sort of things, but there will be different impedance mismatches. I really tried with HATEOAS, because it makes sense, but the overhead has turned out to outweigh the costs for everything we’ve needed.

weq 10y ago

Spoiler alert, if the majority of implementions are "bad", or dont mention HATEOAS then the article is totally justified. REST will live on in memory, as an idea of a utpoia, just not in implementation.

icebraining 10y ago
Nope, the majority of implementations are just fine, and follow HATEOAS pretty closely: they're called "websites". You're using one of them right now.
- deleted 10y ago
  [deleted]

k__ 10y ago

I thought REST didn't define much so basically every API can be REST conform. Just because HATEOAS makes REST APIs better, doesn't mean those without the use of it aren't REST. Even SOAP can be REST conform. Anyway, I guess with the rise of GraphQL, which is more strict (at least in its definition) REST will go away and we will have better dev life's.

icebraining 10y ago
I thought REST didn't define much It does, it's just at a different level. REST is not a protocol, it's a set of architectural constraints, but it's well defined. Only one of the constraints (code-on-demand) is optional. HATEOAS isn't, since you need it to achieve the Uniform Interface that allows you to decouple the clients from the services.

deleted 10y ago

[deleted]