Jan Algermissen wrote: > On Jun 26, 2006, at 9:08 PM, Gregg Wonderly wrote: >>Jan, I suspect you are saying that REST has a uniform API because >>there are an exact set of application layered operations defined by HTTP? > > Well, systems that adhere to the REST arch. style are (by the style) > constrained to > a uniform interface. HTTP is just *one* of such a systems. SMTP is > another system > that has a uniform interface (not to imply that SMTP has a REST arch > style of course).
The predominant theme of REST discussions here has been using HTTP because of the number of resources available today which are visible through HTTP servers. Java RMI has only one operation, INVOKE. Does that make it uniform and thus RESTful? > There is also no problem imposed by adding methods, as long as they > can usefully be > applied to *all* objects of the system. WATCH (aka MONITOR) would be > such a method and > there are also PATCH or MKCOL (from WebDAV). And this can be done with Java interfaces through subclassing without affecting existing users as long as codebases are used for defining the source of classes needed to resolve the clients proxy to the service. >>HTTP GET, PUT and POST have no meaning without a URI. > > Not true. See HTTP specs. The meaning of the operation does *NOT* > depend on what resource it is invoked on. Humm, I believe that without a URI there is only a single service. If you put everything in the payload, then yes, you can move the designation of the action into the payload instead. That is then identical to RMI, CORBA and other RPC transport protocols which have a single operation, INVOKE. >>It is that URI that is >>the denormalizing force for me. > > Can you explain what you mean by 'denormalizing' here? The fact that something different happens on the server based on the URI or an embedded action designation in the payload makes the GET/PUT/POST operation a simple side issue. It doesn't actually make a real difference in what the service WILL do. The implementation of the servlet/cgi/... can consider that operation differently, but any design service could always use POST, and just describe the differentiating action in the payload. GET/PUT/POST are nothing more than 'words' from that perspective. They don't directly describe, to the client, what exactly will happen any better than makeAChangeToThisData(...) does. >>It is exactly that information that is the name >>of the service and operation that you wish to invoke some operation >>on. The >>data that you pass in that request is also varied. > > Hmmm...not sure what you are trying to say. I am saying that there is nothing dictated by the existance of all these bits of the HTTP protocol. They are all fully programmable behaviours. An application designer is free to use/abuse these features of the protocol in whatever way they want which has a denormalizing/non-unifying effect. Specifications which can't be enforced by API are not much of an asset to a programming system, for me. >>It doesn't matter to me how you say >>service1, please add customer Joe Bob Bundy to the database. > > Well, I'd prefer > > srv.addCustomer( bobBundyObj ) over srv.AddCustomerBobBundy() > > and then I'd prefer > > customers = srv.findCollectionByMemberType( "Customer" ) > customers.add( bobBundyObj ) > > over > > srv.addCustomer( bobBundyObj ) > > because it reduces the whole API complexity to a single ADD (aka > POST) operation (the find > operations is of course just a GET and subsequent, say, XPath > expression). There are subtle implications about program architecture which come out of service API design. At the very backend of the server, you will probably find that there are collections and simplified APIs that look like this. But, exposing these to the client, directly, tends to provide the client with more implementation details to depend on and thus creates less flexibility in service updates and changes in API to provide better/different service behaviors. >>In the end all bits and pieces have to travel from a client >>application to the >>environment where the work is done. > > But remember: before the bits travel, the peers have to engage in > communication. And this > is *a lot* simpler and potentially more fruitful when the API is > uniform[1] It is a lot easier when the client and server agree on enough well defined behaviors from both that the contracts implicit in those communications can be met. The more confined and directed an API is, the easier it is for the server to know what the client will depend on. The more confined and directed an API is the less implementation detail is visible to a client. This makes it possible for the service details to evolve such that the client doesn't have to worry about losing access to the service they depend on. Screen scraping HTML for data is a popular tactic on the internet, because we have pushed out HTML for formatting and often don't have parallel interfaces for just the data. So, people have written programs that open HTML URLs, and scrape through documents to extract information that is not otherwise available. It is the lack of a defined contract for such a service that I am speaking of. There is data visible to be consumed, which is not supposed to be consumed in the way it is consumed. There is too much information visible to the client that is not confined into a form that is independent from the container. >>How in the world does HTTP make it possible where anything else >>doesn't? > > Who says that only HTTP can stuff Bob into the customer collection? > HTTP is > just the opposite end to srv.AddCustomerBobBundy(). Again, the RESTful discussions seem to revolve around how many HTTP accessible resources are available. So, I'm focused on why HTTP is of such interest in these discussions. Clearly, any protocol can be used to do this. So, why would you choose HTTP as the ONLY way to do this? > And regarding srv.AddCustomerBobBundy()...would you include *that* in > your > "It doesn't matter to me how you say..." :-) In a sense, this is what finally is resolved to happen no matter what the transport and invocation layer expose as divisions of the data space. srv(addCustomerBobBundy); srv.add(CustomerBobBundy); srv.addCustomer(BobBundy); srv.addCustomerBob(Bundy); srv.addCustomerBobBundy(); All of these could to the work. URLs have the ability to trivially convey all of these variations with URL parsing performing data extraction in some way. But, in each case (in the order shown above) there are fewer constraints of the arguments that you have to understand, respect, and act on. It's this balance that the SOA architect has to find the right balance for. REST vs SOAP vs Jini/RMI vs CORBA is not the biggest issue here. That's my point. SOA is possible with many types of transport/transfer technologies used by these architectures/systems. The question for me is what language/SOA platform provides the most opportunity for system flexibilty, customization, versioning and ultimately security. REST, for me doesn't add value. It recreates existing capabilities. The implementation of these capabilities are not confined in the same way as the previous implementations were. This opening of the doors will lead to very interesting changes. Many think its great that so many implementation details are revealed, because you can use any part of the returned data. It's that level of dependency that locks the service down to what it can do/be. So, as soon as you need to rev the server, you have to understand every possible use of the data that you were returning before. I'm specifically worried about the HTML screen scrapers. I have no issues with well formed resources such as images, executables, XML and other well structured data. But, HTML documents, PDF documents, MSWORD documents and other content which has a standardized form, but which has content that is unstructured is the big issue for me on the web. Because HTTP can be abused in this way, I find fault in its use in a production environment. It enables transfer of information, but because the use of that data can not be constrained to the intended uses (the reason why the service was created to provide such data), I don't find any value in its use. Gregg Wonderly ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
