3 ms·

And if you do that you're really writing POX, with any true-REST features being fifth, sixth, and seventh wheels. Other than systems that post documents tha

by terra_t 16y ago

And if you do that you're really writing POX, with any true-REST features being fifth, sixth, and seventh wheels. Other than systems that post documents that describe state transitions, REST is all about having an inappropriate coupling between your API and your underlying data models.

brown9-2 16y ago
I'm curious, how do you suggest designing a system where the API and domain model are decoupled? Unless we're using the same words to mean different things, I don't see how you could interact with an API method with understanding what you are passing to or receiving from it at a certain level. On the other hand, one of the large selling points of REST-style design is the ability to know how to interact with resource URLs using common http verbs without necessarily knowing what that URL represents - for example, GET or POST have the same meaning throughout the API. I don't think the question of transaction boundaries and REST design are mutually exclusive. One can build a REST system that uses meaningful transactions around it's operations - the obvious solution is to make the operations that are exposed the same as what you want to wrap transactions about, and only expose these operations. In fact I find it strange that some might think these are two exclusive concepts. The other problem you describe sounds like it would be easily solved with client-side caching. REST and caching remote operations are not exclusive of one another either. HTTP provides a very natural way to control caching. Having to make 100 network round trips for the same resource should be unnecessary in any system, REST or not.
- terra_t 16y ago
  It's not 100 trips for the same resource, it's 100 round trips for 100 ~different~ resources that are required to construct a page. Cacheing won't help, and in fact, http caching is one of the #1 obstacles in AJAX programming. People who write AJAX APIs are always using cache-busting methods to make sure that browser caches don't screw up their apps with stale data. The GET model is acceptable for data access (unless you want to radically reduce round trips -- one answer to this is to "virtualize" the REST model and let an app ask for N chunks of data in one request) however, it's bad for data updates, where you're better off exposing operations that exposing data directly. Security, for instance, is easier to implement if you expose operations because security rules most frequently govern state transitions: to apply security rules in purist REST, you're always having to write comparisons between the old state and the new state and you've got to test for every single possible thing that could break security, even combinations of things that would be harmless by themselves. If a security-sensitive operation is exposed as an operation, the implementation of security rules is much more clear.
  - brown9-2 16y ago
    Cacheing won't help, and in fact, http caching is one of the #1 obstacles in AJAX programming. People who write AJAX APIs are always using cache-busting methods to make sure that browser caches don't screw up their apps with stale data. Ah, I was referring to caching requests from the webapp producing the web page to the remote services it's consuming, assuming this was the setup - not browser caching.
metageek 16y ago
>And if you do that you're really writing POX, with any true-REST features being fifth, sixth, and seventh wheels. Not at all. In REST, the resource represents an object. When you GET the resource, you get a document encoding the state of the object. So, if you POST such a document to the creation resource, you're creating the object. CREATE would be a better verb, but WebDAV defines CREATE as creating a resource at the specified URI; in an API, when you want to create a new object, you probably need the API to tell you the URI.
wahnfrieden 16y ago
It sounds like you've worked only with deeply flawed REST APIs. You don't need a 1:1 relation between database tables and REST resources. In fact, you don't actually deal with resources directly, but rather resource representations which can abstract many actual data resources Ina single document. If you're using REST like a naive low-level CRUD ORM, you're probably doing something wrong.

by terra_t 16y ago

brown9-2 16y ago

I'm curious, how do you suggest designing a system where the API and domain model are decoupled? Unless we're using the same words to mean different things, I don't see how you could interact with an API method with understanding what you are passing to or receiving from it at a certain level. On the other hand, one of the large selling points of REST-style design is the ability to know how to interact with resource URLs using common http verbs without necessarily knowing what that URL represents - for example, GET or POST have the same meaning throughout the API. I don't think the question of transaction boundaries and REST design are mutually exclusive. One can build a REST system that uses meaningful transactions around it's operations - the obvious solution is to make the operations that are exposed the same as what you want to wrap transactions about, and only expose these operations. In fact I find it strange that some might think these are two exclusive concepts. The other problem you describe sounds like it would be easily solved with client-side caching. REST and caching remote operations are not exclusive of one another either. HTTP provides a very natural way to control caching. Having to make 100 network round trips for the same resource should be unnecessary in any system, REST or not.

terra_t 16y ago
It's not 100 trips for the same resource, it's 100 round trips for 100 ~different~ resources that are required to construct a page. Cacheing won't help, and in fact, http caching is one of the #1 obstacles in AJAX programming. People who write AJAX APIs are always using cache-busting methods to make sure that browser caches don't screw up their apps with stale data. The GET model is acceptable for data access (unless you want to radically reduce round trips -- one answer to this is to "virtualize" the REST model and let an app ask for N chunks of data in one request) however, it's bad for data updates, where you're better off exposing operations that exposing data directly. Security, for instance, is easier to implement if you expose operations because security rules most frequently govern state transitions: to apply security rules in purist REST, you're always having to write comparisons between the old state and the new state and you've got to test for every single possible thing that could break security, even combinations of things that would be harmless by themselves. If a security-sensitive operation is exposed as an operation, the implementation of security rules is much more clear.
- brown9-2 16y ago
  Cacheing won't help, and in fact, http caching is one of the #1 obstacles in AJAX programming. People who write AJAX APIs are always using cache-busting methods to make sure that browser caches don't screw up their apps with stale data. Ah, I was referring to caching requests from the webapp producing the web page to the remote services it's consuming, assuming this was the setup - not browser caching.

metageek 16y ago

>And if you do that you're really writing POX, with any true-REST features being fifth, sixth, and seventh wheels. Not at all. In REST, the resource represents an object. When you GET the resource, you get a document encoding the state of the object. So, if you POST such a document to the creation resource, you're creating the object. CREATE would be a better verb, but WebDAV defines CREATE as creating a resource at the specified URI; in an API, when you want to create a new object, you probably need the API to tell you the URI.

wahnfrieden 16y ago

It sounds like you've worked only with deeply flawed REST APIs. You don't need a 1:1 relation between database tables and REST resources. In fact, you don't actually deal with resources directly, but rather resource representations which can abstract many actual data resources Ina single document. If you're using REST like a naive low-level CRUD ORM, you're probably doing something wrong.