4 ms·

Can you give an example?

by bct 18y ago

ajross 18y ago
Of protocols that don't work well with REST? Sure: anything that, in the database world, would require transactions. Think of the classic double-entry accounting transaction: you have two accounts, and need to atomically subtract an amount from one and add it to the other. Clearly the accounts are two (or more) REST URIs. But the operation needs to be atomic on both; it's not enough just to do two PUT/POST operations. You can do it with REST, but it requires some fancy footwork with extra objects for "locks" or whatnot. It's just a mess. With a protocol that exposes behavior instead of state? It's just a "DEBIT" command that takes two accounts and an amount and returns success or failure. Basically: pick the tool for the job. A lot of the "problems" with REST are an attempt to make the hype more powerful than the technique.
- bct 18y ago
  The RESTful way to do that would be something like: POST /transactions from: /accounts/savings to: /accounts/chequing amount: 123.45 Generally the proper way to do something atomically is to do it in a single request. REST isn't the best choice for every application - the whole point is that it has certain strengths - but it's very flexible.
  - ajross 18y ago
    No, no, no. That's not RESTful at all. What "thing" does /transactions represent? It's the same URI for every single account in the world? What you've done is break out of the paradigm in order to solve a particular problem, which is great. But don't call it "REST", because the whole point of this discussion is that doing so confuses people about what REST is supposed to mean.
    - bct 18y ago
      It's a collection of transactions. What's unRESTful about that? Collections of things are a very common REST pattern. Naturally you would also want a URI for each account, and it might make sense to have many different collections of transactions. I don't see how that breaks out of the paradigm. Edit: I'm using "transactions" as in "financial transactions" (as opposed to "database transactions")

Can you give an example?

by bct 18y ago

Can you give an example?

Of protocols that don't work well with REST? Sure: anything that, in the database world, would require transactions. Think of the classic double-entry accounting transaction: you have two accounts, and need to atomically subtract an amount from one and add it to the other. Clearly the accounts are two (or more) REST URIs. But the operation needs to be atomic on both; it's not enough just to do two PUT/POST operations. You can do it with REST, but it requires some fancy footwork with extra objects for "locks" or whatnot. It's just a mess. With a protocol that exposes behavior instead of state? It's just a "DEBIT" command that takes two accounts and an amount and returns success or failure. Basically: pick the tool for the job. A lot of the "problems" with REST are an attempt to make the hype more powerful than the technique.

bct 18y ago
The RESTful way to do that would be something like: POST /transactions from: /accounts/savings to: /accounts/chequing amount: 123.45 Generally the proper way to do something atomically is to do it in a single request. REST isn't the best choice for every application - the whole point is that it has certain strengths - but it's very flexible.
- ajross 18y ago
  No, no, no. That's not RESTful at all. What "thing" does /transactions represent? It's the same URI for every single account in the world? What you've done is break out of the paradigm in order to solve a particular problem, which is great. But don't call it "REST", because the whole point of this discussion is that doing so confuses people about what REST is supposed to mean.
  - bct 18y ago
    It's a collection of transactions. What's unRESTful about that? Collections of things are a very common REST pattern. Naturally you would also want a URI for each account, and it might make sense to have many different collections of transactions. I don't see how that breaks out of the paradigm. Edit: I'm using "transactions" as in "financial transactions" (as opposed to "database transactions")