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.
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.
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.
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.
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.
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.
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.
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"
Really? That bad? Care to explain?
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.)
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
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.
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.
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".