3 ms·

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,

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.