5 ms·

I find it hard to believe that he's built real systems that work. Yes, "decomposing services into multiple components" works well when everything is living in

by terra_t 16y ago

I find it hard to believe that he's built real systems that work. Yes, "decomposing services into multiple components" works well when everything is living in the same address space, but if you want to build fast and reliable systems, minimizing round trips is important. If I didn't have anything better to do and if I liked dealing with idiots, I'd hang my shingle as a high-priced consultant who helps "enterprises" dig their way out of the REST morass. Just last year I managed to speed up an application 100x by switching from REST to POX. In this case, the app was doing thousands of round trips for no good reason other than architectural purity. In the real world, composite operations should be done, more or less, in transactions. For instance, in one user authentication system I've worked on, there are about ten database updates to create a new user. There really ought to be one "createUser" call that creates the user. You could probably get away with not having database transactions if you're talking to the database locally, but in a distributed app on the wider internet, you just can't expect to do ten communications in a row and have it work "reliably enough".

troygoode 16y ago
You find it hard to believe that _Martin Fowler_ has built real systems that work? He is a rather well known programmer, author, speaker, and Chief Scientist at ThoughtWorks.
- gruseom 16y ago
  It's a fact about the industry that most such consultants-authors-speakers don't actually build systems themselves and haven't for a long time. If you want to get prominent at it, telling other people how to build things is itself a full-time job. The contradiction here is unfortunately very real.
  - troygoode 16y ago
    I agree in principle, but not when applied to Martin Fowler. I doubt the guy who literally wrote the book on refactoring did so without any real-world experience. http://refactoring.com/catalog/index.html http://refactoring.com/catalog/index.html
    - terra_t 16y ago
      Sure, there was a time he spent a lot of time building OO systems. I don't know how much time he's actually spent building ~distributed~ systems.
    - joe_the_user 16y ago
      I like the book Refactoring too. But I don't think the book, in itself, can cited as evidence that he's built large, real-world systems. There's a big step between "no experience" and "major experience with large scale, distributed systems". When I had six months of programming experience, I could do a fine rendition of the standard OO doctrines. With far more experience now, I can mostly describe how they fail to operate in the real world.
- terra_t 16y ago
  I know who Martin Fowler is. I love his "Refactoring" book. On the other hand, once you get famous, you can go around and get big $ telling people what they want to hear and you can lose your edge. If this is representative of his work these days, he should preface it with something like "I'm not a doctor but I play one on TV"
  - deleted 16y ago
    [deleted]
  - shadowfox 16y ago
    > If this is representative of his work these days, he should preface it with something like "I'm not a doctor but I play one on TV" Really? That bad? Care to explain?
nwatson 16y ago
A follow-up question regarding REST, transactions, and doing multiple things at the same time ... I see the REST services in the article expose some very fine-grained concepts, e.g., existence of patients, doctors, and "slots", i.e., appointments. It appears the REST services can readily let one patient book one slot to see one doctor, but most real-world systems aren't like this. So ... What's the REST-y way to address this situation then, that's a bit more complex: (a) there are a number of conference rooms; (b) each conference room can be reserved for a contiguous set of 15-minute slots; (c) a client using the REST-y interface wants to fully reserve N 15-minute slots in a particular room, and either completely succeed or completely fail. Is there a REST-y way to do this or would one need to rely on some client-driven pseudo-transaction mechanism? (This is kind of similar to the parent's complaint about needing the "createUser" call.)
- terra_t 16y ago
  I saw a nice example that covered the classic "bank account transfer" case. The answer was that you POST something that's like a deposit slip. Some systems, like the Kuali accounting system, use a document-centric approach to business software. You can have a workflow that's much like a traditional paper-based system, so this can make a lot of sense. You can overlay this on top of REST to solve many of the problems that REST has, but then you end up with much of REST being just a fifth wheel. As for ranges, lately I've been sketching up a hypertext system that has some inspiration from Ted Nelson's Xanadu system. In particular, hyperlinks can be made to and from arbitrary ranges in documents, without touching the documents directly. You can certainly encode ranges in a URL, so something like /conference_room_3/time_slot_7,time_slot_12 might be POSTable to
- brown9-2 16y ago
  As terra_t outlines, introduce a "Reservation" resource which contains 1 or more slots, allowing someone to (attempt to) create a Reservation containing several 15-minute slots in a single request. If "N 15 minute slots" are something that you want to either all suceed or all fail at the same time, then what you really have in this concept is another entity/resource to add to your model.
metageek 16y ago
>For instance, in one user authentication system I've worked on, there are about ten database updates to create a new user. That strikes me as a strawman, because the obvious RESTful way to do that would be to POST a document fully describing the new user. Mind you, I don't doubt that you've seen this in a RESTful API. You can write Java Beans in any language.
- 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.
deleted 16y ago
[deleted]
- terra_t 16y ago
  You read the article? The first thing he does is call POX "level 0" and "the swamp". Generally, real http APIs from companies like Amazon, Flickr, Twitter, etc. are POX-RPC APIs, the idea is that you're exposing operations, not data structures. REST is a castles-in-the-air exercise in exploring the dark corners of the http specification and exposing data directly instead of exposing operations on the data.
Confusion 16y ago
Quoting wikipedia on POX: POX is complementary to REST: REST refers to a communication pattern, while POX refers to an information format style

by terra_t 16y ago

troygoode 16y ago

You find it hard to believe that _Martin Fowler_ has built real systems that work? He is a rather well known programmer, author, speaker, and Chief Scientist at ThoughtWorks.

gruseom 16y ago
It's a fact about the industry that most such consultants-authors-speakers don't actually build systems themselves and haven't for a long time. If you want to get prominent at it, telling other people how to build things is itself a full-time job. The contradiction here is unfortunately very real.
- troygoode 16y ago
  I agree in principle, but not when applied to Martin Fowler. I doubt the guy who literally wrote the book on refactoring did so without any real-world experience. http://refactoring.com/catalog/index.html http://refactoring.com/catalog/index.html
  - terra_t 16y ago
    Sure, there was a time he spent a lot of time building OO systems. I don't know how much time he's actually spent building ~distributed~ systems.
  - joe_the_user 16y ago
    I like the book Refactoring too. But I don't think the book, in itself, can cited as evidence that he's built large, real-world systems. There's a big step between "no experience" and "major experience with large scale, distributed systems". When I had six months of programming experience, I could do a fine rendition of the standard OO doctrines. With far more experience now, I can mostly describe how they fail to operate in the real world.
terra_t 16y ago
I know who Martin Fowler is. I love his "Refactoring" book. On the other hand, once you get famous, you can go around and get big $ telling people what they want to hear and you can lose your edge. If this is representative of his work these days, he should preface it with something like "I'm not a doctor but I play one on TV"
- deleted 16y ago
  [deleted]
- shadowfox 16y ago
  > If this is representative of his work these days, he should preface it with something like "I'm not a doctor but I play one on TV" Really? That bad? Care to explain?

nwatson 16y ago

A follow-up question regarding REST, transactions, and doing multiple things at the same time ... I see the REST services in the article expose some very fine-grained concepts, e.g., existence of patients, doctors, and "slots", i.e., appointments. It appears the REST services can readily let one patient book one slot to see one doctor, but most real-world systems aren't like this. So ... What's the REST-y way to address this situation then, that's a bit more complex: (a) there are a number of conference rooms; (b) each conference room can be reserved for a contiguous set of 15-minute slots; (c) a client using the REST-y interface wants to fully reserve N 15-minute slots in a particular room, and either completely succeed or completely fail. Is there a REST-y way to do this or would one need to rely on some client-driven pseudo-transaction mechanism? (This is kind of similar to the parent's complaint about needing the "createUser" call.)

terra_t 16y ago
I saw a nice example that covered the classic "bank account transfer" case. The answer was that you POST something that's like a deposit slip. Some systems, like the Kuali accounting system, use a document-centric approach to business software. You can have a workflow that's much like a traditional paper-based system, so this can make a lot of sense. You can overlay this on top of REST to solve many of the problems that REST has, but then you end up with much of REST being just a fifth wheel. As for ranges, lately I've been sketching up a hypertext system that has some inspiration from Ted Nelson's Xanadu system. In particular, hyperlinks can be made to and from arbitrary ranges in documents, without touching the documents directly. You can certainly encode ranges in a URL, so something like /conference_room_3/time_slot_7,time_slot_12 might be POSTable to
brown9-2 16y ago
As terra_t outlines, introduce a "Reservation" resource which contains 1 or more slots, allowing someone to (attempt to) create a Reservation containing several 15-minute slots in a single request. If "N 15 minute slots" are something that you want to either all suceed or all fail at the same time, then what you really have in this concept is another entity/resource to add to your model.

metageek 16y ago

>For instance, in one user authentication system I've worked on, there are about ten database updates to create a new user. That strikes me as a strawman, because the obvious RESTful way to do that would be to POST a document fully describing the new user. Mind you, I don't doubt that you've seen this in a RESTful API. You can write Java Beans in any language.

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.

deleted 16y ago

[deleted]

terra_t 16y ago
You read the article? The first thing he does is call POX "level 0" and "the swamp". Generally, real http APIs from companies like Amazon, Flickr, Twitter, etc. are POX-RPC APIs, the idea is that you're exposing operations, not data structures. REST is a castles-in-the-air exercise in exploring the dark corners of the http specification and exposing data directly instead of exposing operations on the data.

Confusion 16y ago

Quoting wikipedia on POX: POX is complementary to REST: REST refers to a communication pattern, while POX refers to an information format style