3 ms·

REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers. CRUD API would

by fooyc 5y ago

REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers. CRUD API would be a good name.

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...
SahAssar 5y ago
I'm pretty sure netflix, spotify, notion, airtable, github and many others can be modeled as pretty pure data transfers. What am I missing? What internet-based service is not using data transfer as its base for building services on top of?
- fooyc 5y ago
  Indeed you can interpret my comment like that, so I will rephrase it in an other way: REST represents everything as a resources and the creation, update, and retrieval of resources. Unless your business is fundamentally about storage without any kind of associated logic, REST will be a bad design choice. Why limit yourself to 4 verbs ? This is insane. Your business has more semantics than create, read, update, delete. Git has commit, rebase, branch, tag, revert, amend, clone, and so has GitHub. A good API will represent these actions as actions and not as a convoluted mess of resource creations or updates. There is an impedance mismatch between REST and most businesses, like there is an impedance mismatch between an ORM and a relational database.
  - SahAssar 5y ago
    I think we're talking about slightly different things. I'm using REST as an interface to a storage (of blobs/objects/whatever), just like you would SQL SELECT, UPDATE, INSERT, DELETE. I then add more things that listens to changes to that storage, so the data is sortof the API. You're talking about putting the API layer upfront so you'd have a REBASE verb in the same layer that we have GET/POST or SELECT/INSERT etc. Your example of git easily abstracts on my view since it already does those basic operations, but not on yours since you'd need a separate REBASE verb and so on as a part of the protocol. I think we just have different expectations of the protocol.
    - fooyc 5y ago
      > I'm using REST as an interface to a storage > I then add more things that listens to changes to that storage, so the data is sortof the API. I get it, but that's exactly the issue. Data changes are a lossy way to represent business actions/intents. Why would you represent your service as a storage ? Is your business about data storage ? If not, that's the wrong abstraction. What's the advantage of this ? > You're talking about putting the API layer upfront so you'd have a REBASE verb in the same layer that we have GET/POST or SELECT/INSERT etc. I would definitely _not_ do that. Separation of concerns tells me to not mix the transport layer with other concerns. HTTP is just a transport, business semantics have nothing to do in this layer.

by fooyc 5y ago

REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers. CRUD API would be a good name.

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

SahAssar 5y ago

I'm pretty sure netflix, spotify, notion, airtable, github and many others can be modeled as pretty pure data transfers. What am I missing? What internet-based service is not using data transfer as its base for building services on top of?

fooyc 5y ago
Indeed you can interpret my comment like that, so I will rephrase it in an other way: REST represents everything as a resources and the creation, update, and retrieval of resources. Unless your business is fundamentally about storage without any kind of associated logic, REST will be a bad design choice. Why limit yourself to 4 verbs ? This is insane. Your business has more semantics than create, read, update, delete. Git has commit, rebase, branch, tag, revert, amend, clone, and so has GitHub. A good API will represent these actions as actions and not as a convoluted mess of resource creations or updates. There is an impedance mismatch between REST and most businesses, like there is an impedance mismatch between an ORM and a relational database.
- SahAssar 5y ago
  I think we're talking about slightly different things. I'm using REST as an interface to a storage (of blobs/objects/whatever), just like you would SQL SELECT, UPDATE, INSERT, DELETE. I then add more things that listens to changes to that storage, so the data is sortof the API. You're talking about putting the API layer upfront so you'd have a REBASE verb in the same layer that we have GET/POST or SELECT/INSERT etc. Your example of git easily abstracts on my view since it already does those basic operations, but not on yours since you'd need a separate REBASE verb and so on as a part of the protocol. I think we just have different expectations of the protocol.
  - fooyc 5y ago
    > I'm using REST as an interface to a storage > I then add more things that listens to changes to that storage, so the data is sortof the API. I get it, but that's exactly the issue. Data changes are a lossy way to represent business actions/intents. Why would you represent your service as a storage ? Is your business about data storage ? If not, that's the wrong abstraction. What's the advantage of this ? > You're talking about putting the API layer upfront so you'd have a REBASE verb in the same layer that we have GET/POST or SELECT/INSERT etc. I would definitely _not_ do that. Separation of concerns tells me to not mix the transport layer with other concerns. HTTP is just a transport, business semantics have nothing to do in this layer.