4 ms·

It is not overhyped at all. It is misunderstood. If you pick an API stack, consider your users. If you build an API for general consumption that you want to gr

by beders 5y ago

It is not overhyped at all. It is misunderstood. If you pick an API stack, consider your users. If you build an API for general consumption that you want to gradually evolve and that should remain valid years from now, a RESTful API with HATEOS is a great choice. If you need to drive a UI from your API and you control that UI, use something that makes you more productive and can be easily changed on both ends quickly - without regards to backward compatibility. Not sure I understand: > No business can be modeled purely as data transfers. Most businesses can, unless you have a very different definition of what a data transfer is.

fooyc 5y ago
Most business can in a convoluted way. But should you they? Take HN as an example. People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Or as an action ? Take Amazon, how do you represent the action of putting a cart item aside ? The action of paying ? The action of changing which card is the default one ?
- sseagull 5y ago
  Thanks for putting it succinctly. I was going over some REST design principles and the "no verbs in the URL" thing is just really awkward and not intuitive (and something being non-intuitive leads to complexity in my opinion). As in your examples, people think in terms of data (noun) and what they want to do with it (verb). Cramming everything into 4-ish verbs makes it awkward. The solution given for this is usually to put the action in the body. But that feels like working around a limitation that doesn't even have to be there.
- conradludgate 5y ago
  > People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Maybe yes. Likes are a relationship between a User and a Post/Comment. In a standard normalised relational db model, they would have their own table. So `PUT /like` would add a Like to that table
  - GauntletWizard 5y ago
    I'm a normalization anti - I believe that many normalized tables are an antipattern and that likes are better stored not as their own table but as a list within the comment row - And I still believe that `PUT /like` is the right pattern to use, and that likes should be thought of as their own resource in a RESTful way.
  - fooyc 5y ago
    But should you design your API like a data store ? That's my whole point actually. Do you design anemic domain models, or models that represent just data without any kind of logic ? If yes, I guess REST is ok as well.
  - motogpjimbo 5y ago
    How is saying "I like a comment by adding a like to the list of likes" better than just saying "I like this comment"? I genuinely don't understand why REST advocates think it's a good idea to divorce an application's data model from its business logic, as if the business logic is a minor implementation detail that can be ignored. HN allows users to like comments. All it needs is a `/like-comment` endpoint that you pass a comment ID to. Anything else is pointless mental masturbation. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
felipellrocha 5y ago
> It is not overhyped at all. It is misunderstood. How many times have I heard that...

by beders 5y ago

fooyc 5y ago

Most business can in a convoluted way. But should you they? Take HN as an example. People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Or as an action ? Take Amazon, how do you represent the action of putting a cart item aside ? The action of paying ? The action of changing which card is the default one ?

sseagull 5y ago
Thanks for putting it succinctly. I was going over some REST design principles and the "no verbs in the URL" thing is just really awkward and not intuitive (and something being non-intuitive leads to complexity in my opinion). As in your examples, people think in terms of data (noun) and what they want to do with it (verb). Cramming everything into 4-ish verbs makes it awkward. The solution given for this is usually to put the action in the body. But that feels like working around a limitation that doesn't even have to be there.
conradludgate 5y ago
> People can upvote comments. Should you represent the action of upvoting as a resource creation, in a REST way ? Maybe yes. Likes are a relationship between a User and a Post/Comment. In a standard normalised relational db model, they would have their own table. So `PUT /like` would add a Like to that table
- GauntletWizard 5y ago
  I'm a normalization anti - I believe that many normalized tables are an antipattern and that likes are better stored not as their own table but as a list within the comment row - And I still believe that `PUT /like` is the right pattern to use, and that likes should be thought of as their own resource in a RESTful way.
- fooyc 5y ago
  But should you design your API like a data store ? That's my whole point actually. Do you design anemic domain models, or models that represent just data without any kind of logic ? If yes, I guess REST is ok as well.
- motogpjimbo 5y ago
  How is saying "I like a comment by adding a like to the list of likes" better than just saying "I like this comment"? I genuinely don't understand why REST advocates think it's a good idea to divorce an application's data model from its business logic, as if the business logic is a minor implementation detail that can be ignored. HN allows users to like comments. All it needs is a `/like-comment` endpoint that you pass a comment ID to. Anything else is pointless mental masturbation. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

felipellrocha 5y ago

> It is not overhyped at all. It is misunderstood. How many times have I heard that...