RESTing up for Ch5

REST to me seems like a mapping of a relational database to the world of the web. Only 4 verbs?  That's fine...SQL's done just fine with SELECT, INSERT, UPDATE, and DELETE for years.  REST implies that you can layer on an arbitrary level of complexity in the type of query logic you can express, so I don't see it being restrictive there...

Really, aren't all systems "data" oriented?  Whether you consider "data" to be the state of your object graph, or fields in a database table, the purpose of software in general is to manage data.  Sometimes it's de-emphasized and subordinated to the workflows or behaviors that a system presents, but thats just semantics.

While I can see that it could be useful to always go to the same URL for the same data, I'm not sure how well this would work for a lot of compound querying.  It goes back to invoking behaviors, but at some point, the system is going to exhibit behaviors, and they have to be invoked somehow, so whether you consider it to be a type of query on one of the types of data involved, or a separate contract, there are still going to be situations where you need to do something that involves a bunch of different types of data, and return a bunch of different types of data.  Now where should we implement such an operation?  I don't think that REST makes this very clear.

In fact, I think that what REST tries to do has been a common theme throughout the evolution of the software world.  Someone will come up with a system that represents something well, and then through time, extensions will be added to it until it can do everything that everyone wants, by which point everyone considers it bloated, and starts looking towards a "simpler" format to accomplish the current view of what the core functions are, but in the process, they abandon a lot of power that has been built into previous systems/formats.  I think REST falls into this same trap.  Sure, it makes the idea of finding the same data in the same place, and offers some benefits such as architectural memoization, but falls short at specifying how query/selection logic, as well as behavior invocation should be handled.  So the next step is that someone will develop some extension that standardizes that, and we'll be further away from the utopian view of what REST should be, and not a whole lot better off than we were with web services.

Don't get me wrong, each new such technology leverages advances throughout computing, and the evolved system is usually better than its predecessors, but I don't know why each such advancement has to be a paradigm shift.  Why can't we just go back and revise existing standards and trim the fat and extend towards the future?

This chapter emphasizes "not being tied to certain infrastructure", but the reality of things is that you probably will be tied to quite a bit.  You'll end up building your system on a set of libraries and frameworks, and with certain methodologies which work nicely with your current technology stack, but if you were to want to make  a serious infrastructure change, it'll be no easy task no matter what.  Wasn't the purpose of the IP protocol so that different systems with different physical architectures, scales, and purposes could all talk to one another in a common method?  In the same way that IP has grown into a bunch of different vendor specific formats, etc. such shall REST, and as most things, I doubt it will live up to the hype that it has presented.

From a pragmatic view, it's just another different perspective on data, and one more layer of indirection in the world to resolve resources.