Agreed, actions should be represented as nouns. It's just that rest tends not to encourage this and this seems to be what happened to the author. He should have a sale resource and put to it but because he doesn't he transfers the price to the client which then gets out of date. The client is being coupled to the server and the server lacks cohesion; all for the lack of thinking in terms of actions/behaviours at the interface level. Instead he is putting the behaviour in the client.
I saw a comment from Fielding that touted this as a benefit of rest. Expose the data and the clients have freedom to use it in ways the server never imagined. Good for mashups maybe. Not so good for accounting systems.
> Agreed, actions should be represented as nouns. It's just that rest tends not to encourage this
How, specifically, is this the case -- what is it about REST that is concretely bad for this compared to alternatives?
As I see it, REST is about what you do with your ___domain model, not how you make the ___domain model. They are orthogonal concerns; people very often suck at ___domain modelling, but that's not any architectural pattern's fault.
> He should have a sale resource and put to it but because he doesn't he transfers the price to the client which then gets out of date. The client is being coupled to the server and the server lacks cohesion; all for the lack of thinking in terms of actions/behaviours at the interface level.
And how is choosing the wrong resources REST's fault?
I saw a comment from Fielding that touted this as a benefit of rest. Expose the data and the clients have freedom to use it in ways the server never imagined. Good for mashups maybe. Not so good for accounting systems.