3 ms·

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 re

by 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

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.