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