Gregg, I think you got things switched around. The REST proponents tell us that everything that you might be interested in (i.e., resources) is its own service, but every service (i.e., resource) exposes a uniform interface. I don't think anyone has ever said that there's no software behind the uniform interface. Obviously, when you POST an <order> to an "orders" resource, some software will be executed to accept the order. Likewise, when you GET orders that are on backorder, some additional software will be executed to retrieve the list of backordered orders.
Anne On 6/15/07, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
Eric Newcomer wrote: > Yes, I think OO is too complex, and it's simpler and better to model the > world using services. > > OO doesn't map well to things like procedures and asynchronous message > queues. I really have to ask what you call OO here Eric. For me objects are services. Whether you access them locally or remotely, requires some different treatment of the services, but in general, Objects should be considered services focused on a particular type of data. The REST proponents tell us there should only be one service that accepts all types of data. But I've yet to see a web server that writes its own servlets, or provides you programmability as a thought only process. So, application specifics are always codified in some form of software that someone has to write and put in place somewhere. The bigger issue that revolves around web services is whether you pass the data to the action, or perform some action on the data. The HTTP protocol is structured around the notion that you have operations that exist everywhere, and you can pass data to those operations. The imaginery view, of course is that behind GET, POST, PUT etc there is "no software". GET, POST, PUT etc. are the application interface, but in reality they just provide a control interface to allow client software to hand data to service software with implied (but not enforced by the interface, only by correct implementation) constraints. This, of course, is where all the arguments and discussions revolve. Is it better for software programmers to only be able to call data objects "data", and pass them to services? Or, is it better if they are called things like Orders, People, PDF documents, UML documents, Java source files etc, and then approriate uses codified either with those "items" or elsewhere. Some object types work with data inside the object. Other object types work with data provided to them. Object types that are data with code are what many people call OO and where all the arguments about generic interfaces come from. Objects which act on data passed to them are more in line with the service description that RESTful services have. What seems to be missing in many of these "REST has a one interface" and "OO has specific interfaces" is the realization that you can have both in the same system, and that is when objects become services instead of just objects. Gregg Wonderly
