4 ms·

Thanks for the response but I Don't think 2. I think that rest encourages thinking about the nouns rather than the verbs and ends up exposing too much state to

Thanks for the response but I Don't think 2. I think that rest encourages thinking about the nouns rather than the verbs and ends up exposing too much state to the client. His first example shows the client dereferencing the product id in other to figure out how much to charge. The client should not be doing that. If he was thinking in verbs it would naturally come out as make_sale(product, customer). But REST has only a few verbs which kind of hobbles your ability for expression.

dragonwriter 12y ago
> I think that rest encourages thinking about the nouns rather than the verbs Sure -- but actions and events that need to be represented are nouns, even if they are instance of behavior that can be described with verbs. In fact, they are usually the most important nouns. There's nothing about REST that encourages missing this point, although there may be something about the common tutorial-type material which tends to focus on simple examples where, unlike most non-toy applications, this is not the case and the important entities are not actions. But that's because they are examples of implementing REST, not examples of domain modelling for complex application domains. > But REST has only a few verbs which kind of hobbles your ability for expression. HTTP (if not extending it, which without very good cause you shouldn't in REST if HTTP is used as the communication channel) has only a few methods. But the methods of the communications channel are not the verbs of the domain, nor ought they map to the kinds of actions in the domain. There's a particularly common, but flawed, naive approach to domain modelling which maps the obvious nouns of the domain to entities/resource in the model and tries to map actions in the domain to methods in the medium in which the model is instantiated [1]. But this almost always ends up biting you -- instance of actions are nouns and need to be entities/resources too. If you do this, the more-obvious nouns of the domain tend to end up being read-only or read-mostly entities over the exposed interface, with most or all of the mutations happening through the entities/resources representing actions. [1] While this happens with REST, it happens with other architectural patterns as well, and with different levels of application implementation -- not just web interfaces.
- discreteevent 12y ago
  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.
  - dragonwriter 12y ago
    > 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?
steego 12y ago
> If he was thinking in verbs it would naturally come out as make_sale(product, customer). If you think about verbs as messages (data), then you would simply POST a make_sale(product, customer) message to some URL, and your RESTful interface will redirect you to the URL of the sale you just posted.
- dragonwriter 12y ago
  > If you think about verbs as messages (data), then you would simply POST a make_sale(product, customer) message to some URL I would say instead that if you were thinking in actions-as-domain-resources, then you would post a "sale(product, customer)" entity to a "sales" collection resource (via POST to the appropriate URL, in an HTTP API) -- which is pretty much the same thing, though not calling it "make_sale" is more REST-appropriate; the combination of the operation and the resource should make the "make" part superfluous.

dragonwriter 12y ago

> I think that rest encourages thinking about the nouns rather than the verbs Sure -- but actions and events that need to be represented are nouns, even if they are instance of behavior that can be described with verbs. In fact, they are usually the most important nouns. There's nothing about REST that encourages missing this point, although there may be something about the common tutorial-type material which tends to focus on simple examples where, unlike most non-toy applications, this is not the case and the important entities are not actions. But that's because they are examples of implementing REST, not examples of domain modelling for complex application domains. > But REST has only a few verbs which kind of hobbles your ability for expression. HTTP (if not extending it, which without very good cause you shouldn't in REST if HTTP is used as the communication channel) has only a few methods. But the methods of the communications channel are not the verbs of the domain, nor ought they map to the kinds of actions in the domain. There's a particularly common, but flawed, naive approach to domain modelling which maps the obvious nouns of the domain to entities/resource in the model and tries to map actions in the domain to methods in the medium in which the model is instantiated [1]. But this almost always ends up biting you -- instance of actions are nouns and need to be entities/resources too. If you do this, the more-obvious nouns of the domain tend to end up being read-only or read-mostly entities over the exposed interface, with most or all of the mutations happening through the entities/resources representing actions. [1] While this happens with REST, it happens with other architectural patterns as well, and with different levels of application implementation -- not just web interfaces.

discreteevent 12y ago
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.
- dragonwriter 12y ago
  > 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?

steego 12y ago

> If he was thinking in verbs it would naturally come out as make_sale(product, customer). If you think about verbs as messages (data), then you would simply POST a make_sale(product, customer) message to some URL, and your RESTful interface will redirect you to the URL of the sale you just posted.

dragonwriter 12y ago
> If you think about verbs as messages (data), then you would simply POST a make_sale(product, customer) message to some URL I would say instead that if you were thinking in actions-as-domain-resources, then you would post a "sale(product, customer)" entity to a "sales" collection resource (via POST to the appropriate URL, in an HTTP API) -- which is pretty much the same thing, though not calling it "make_sale" is more REST-appropriate; the combination of the operation and the resource should make the "make" part superfluous.