4 ms·

First, let me caveat: I'm not a REST expert, but I've been known to pretend to be one. It seems to me you're under the impression that REST tends to lead to s

by steego 12y ago

First, let me caveat: I'm not a REST expert, but I've been known to pretend to be one. It seems to me you're under the impression that REST tends to lead to systems that: 1. Transfer logic to the client 2. Put the client in charge with modifying the state 3. Lack Behavioral APIs. Too many people assume RESTful services are these simplistic services that return JSON objects, which are then modified by the client and PUT back on the server. This isn't the case. When you request a resource (think object) from a RESTful service, it doesn't just send you its state. It sends you its state and metadata describing the interface in which you can interact with this resource. If you we were talking about an HR database, requesting an employee object would not only return the employee's data, it would also include relevant metadata on how to request vacation days. That operation is not a PUT operation, it's likely you'd POST a vacation-request message to a URL that would start some sort of workflow. A RESTful architecture is very good at behaving like a network file system by default, but it can also support behavioral interfaces in a RESTful way when you need them using POST. You may be familiar with the CQRS architecture, which explicitly separates commands from queries when designing APIs. The idea is anything queries your system should *never* change its state, and anything that changes the state of a system should be sent as a one-way message. If you've done CQRS correctly, it should be easy to log all messages that change your system's state similar to a database transaction log. A RESTful architecture makes the same demands and then some more. 1. If you're implementing GET, don't modify the state. 2. If you're implementing PUT, it should modify the resource addressed at the URL and it should be idempotent. 3. If a resource implements POST, you get none of the above guarantees. So, I don't think REST prevents behavioral API's so much as it demands that anything behavioral is POSTed as command-based message.

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

by steego 12y ago

discreteevent 12y ago

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.