5 ms·

So, separating your REST API into indexes and values effectively creates a database over HTTP. This transfers complexity to the client though, which I don't thi

So, separating your REST API into indexes and values effectively creates a database over HTTP. This transfers complexity to the client though, which I don't think is the point of having an API in the first place (you could just give clients the login to your database).

discreteevent 12y ago
The problem that I see with REST is that it leads in general to APIs that tend to transfer logic to the client. This is basically a loss of encapsulation and makes it harder to change the server implementation later without breaking clients. It took a long time for the industry to move towards behavioural interfaces for good reasons. Are those reasons now void? I know that there is some encapsulation because only a representation is transferred but still, REST interfaces tend to represent state and not behaviour. Am I wrong?
- 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.
      - 12y ago
- hcarvalhoalves 12y ago
  The good thing about REST is that the limited vocabulary enforces good design practices, but it doesn't save you from fundamental problems. On the article, that would be the conceptual mistake of considering the price is an attribute of the product, which in turn would require a second request to retrieve, then breaking the atomicity of having all the necessary state in a single request. To solve that, he proposed a "database over REST", where the main resources act like an index - thus increasing the abstraction by one notch and moving some complexity to the client. This doesn't solve a problem inherent to REST, but rather a conceptual problem that applies to all data systems, which is how to maintain and recall states in an atomic way.
- dragonwriter 12y ago
  > The problem that I see with REST is that it leads in general to APIs that tend to transfer logic to the client. That's just bad API design -- specifically poorly chosen resources. > I know that there is some encapsulation because only a representation is transferred but still, REST interfaces tend to represent state and not behaviour. Am I wrong? They by definition transfer the state of a resource. So, in a trivial sense, you are correct. Substantively, though, there is no reason an individual REST resource couldn't be an instance of a behavior, or that state modifications to a resource couldn't trigger modifications to many back-end entities (and other front-end exposed resources.) To use RDBMS languages, REST resources are often treated like base tables when they should be more like application-specific updateable views. This has nothing to do with REST architecture, and everything to do with the fact that domain modelling is harder than implementing an API, and yet (regardless of the architecture chosen for the API) people often spend more effort on implementing the API than designing the domain model.
  - discreteevent 12y ago
    Yes, getting a domain model right up front can be very hard. That's why behavioural interfaces that hide as much as possible were found to be more forgiving when we realise that we failed to predict the future correctly when dreaming up V1 of the product. They make it easier to evolve.
    - deleted 12y ago
      [deleted]

discreteevent 12y ago

The problem that I see with REST is that it leads in general to APIs that tend to transfer logic to the client. This is basically a loss of encapsulation and makes it harder to change the server implementation later without breaking clients. It took a long time for the industry to move towards behavioural interfaces for good reasons. Are those reasons now void? I know that there is some encapsulation because only a representation is transferred but still, REST interfaces tend to represent state and not behaviour. Am I wrong?

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.
    - 12y ago
hcarvalhoalves 12y ago
The good thing about REST is that the limited vocabulary enforces good design practices, but it doesn't save you from fundamental problems. On the article, that would be the conceptual mistake of considering the price is an attribute of the product, which in turn would require a second request to retrieve, then breaking the atomicity of having all the necessary state in a single request. To solve that, he proposed a "database over REST", where the main resources act like an index - thus increasing the abstraction by one notch and moving some complexity to the client. This doesn't solve a problem inherent to REST, but rather a conceptual problem that applies to all data systems, which is how to maintain and recall states in an atomic way.
dragonwriter 12y ago
> The problem that I see with REST is that it leads in general to APIs that tend to transfer logic to the client. That's just bad API design -- specifically poorly chosen resources. > I know that there is some encapsulation because only a representation is transferred but still, REST interfaces tend to represent state and not behaviour. Am I wrong? They by definition transfer the state of a resource. So, in a trivial sense, you are correct. Substantively, though, there is no reason an individual REST resource couldn't be an instance of a behavior, or that state modifications to a resource couldn't trigger modifications to many back-end entities (and other front-end exposed resources.) To use RDBMS languages, REST resources are often treated like base tables when they should be more like application-specific updateable views. This has nothing to do with REST architecture, and everything to do with the fact that domain modelling is harder than implementing an API, and yet (regardless of the architecture chosen for the API) people often spend more effort on implementing the API than designing the domain model.
- discreteevent 12y ago
  Yes, getting a domain model right up front can be very hard. That's why behavioural interfaces that hide as much as possible were found to be more forgiving when we realise that we failed to predict the future correctly when dreaming up V1 of the product. They make it easier to evolve.
  - deleted 12y ago
    [deleted]