02/28/08 :: [REST] REST easy... [permalink]
Steve got his best shot at explaining how ...
the uniform-interface constraint reduces client-server coupling and helps minimize gratuitous differences in interface and method semantics across disparate resources.
So here he starts:
One is that different resources should each have specific interfaces and methods that more accurately reflect their precise functionality.
But, Steve, have you considered that information systems where invented 8000 years ago? Have you ever understood that information systems are independent of computers and programming languages? Do you understand that you "inter-act" with information, you just don't crud around at will? You also query or research information, and it subscribes to or produces events (the occurrence of a particular state). This is inherent to information, independent of any programming model. This is not engrained in the minds of the developers, this is engrained in information systems design, of which you seem to ignore the most basic details.
those who raise this objection fail to properly consider the effects of networking and distribution.
If you ignore "inter-actions" and events and you try to remote your crud operations, sure enough what you say is true. Inter-actions are the easiest to monitor and "intermediate" because they represent a unit of work. Just try to intermediate or monitor when someone is cruding around.
You continue:
As we’ll see, the purpose and form of exchanged data in REST differ significantly from those of other systems
So you explain:
the definitions they encourage greatly resemble typical programming language method definitions.
But do you understand just a thing about XML? Do you understand that X stands for eXtensible? Have you ever seen an IDL prior to WSDL that enabled forward compatibility? No, XML does not represent any think like structures in a traditional programming language. Do you understand that you can create "projection" of an XML document, you can transform it at will, and most importantly, you can access its content semantically without ever understanding the overall structure of the document, using relative XPath statements. Do you think you can achieve things like CAM or CCTS in "traditional programming languages"? Where do you come from, where have you been for the past 10 years? Don't you ever talk to Tim? This is no RPC, just like WSDL is an "inter-action" definition language which supports "Orchestration" and "Choreography". Again, where have you been? what are you talking about?
Consider the coupling that these constructed types induce within a local application between a caller and a function or method it calls.
Precisely, this is the whole beauty of XML, it is nothing to do with the "uniform" interface.
The caller and called method are also either compiled together into the same application or are strongly connected via dynamic loading
Again, this is a very surprising statement for somebody who lead the development of an ESB. I can appreciate why some people are criticizing some aspects of an ESB, but you can't argue that an ESB makes your statement above invalid. If you look at Oracle SOA Suite 11g, you will see that they reduced the ESB to its right size a "mediator" component that can be put in place in an assembly precisely to avoid consumer and provider to be totally coupled.
Either way, changing the constructed type’s definition means recompiling both the caller and the called method.
This could not be more fallacious. You want us to make the connection "this is what happen in Java and C++", "Java and C++ are RPC", by the way "WSDL is RPC too right?" therefore it is true for WSDL. Do you think your readers are stupid? Why do you propagate such false statements?
And you don't stop here, here is the best statement of your paper:
changing the definition of any specialized data type shared across those applications is fraught with problems.
Really? because now, REST does not even share data definitions? a uniform interface and a blob of data, naturally, pick what you want, and voila. In REST you don't share anything, of course, why didn't I think of that before? I really thought that the reviewers at IEEE IC where a bit better to avoid letting this kind of thing pass through but I guess not.
A client might also replace the state of the employee details by using PUT to send a new state representation, also in HTML form.
Yes, of course, this is super realistic. Why don't I PUT the new balance of my bank account? That'd be a lot easier. The bank would save money with less IT people that write useless business logic.
Resource representations do, however, help alleviate some datacoupling problems because they’re not tied to the underlying protocol.
You mean the content of a SOAP Body is of course tied to the SOAP protocol? right?
A REST resource’s ability to handle state representations in different formats makes it easier to support a wider variety of client applications. It lets clients minimize their data coupling to the resource by choosing which representation is best for them.
Yes this is of great value, as noted yesterday. At least we agree on something.
In HTTP, message payloads are identified using standard Internet Assigned Numbers Authority (IANA) Multipurpose Internet Mail Extensions (MIME) media types.
Has anyone looked at the IANA Media Types web site? I am sure every one who has decided to walk away from REST. Why don't you compare this one (picked totally randomly) to an XML Schema definition of a message type in WSDL? Natural Language it is. And of course as you write an application you are going to expose you media type definition to IANA and the world, write an RFC, submit it to the Internet Society.
The fact that IANA controls these media type definitions means that they’ll never change, which eliminates a lot of versioning related churn and uncertainty.
Wow, you mean, once I submitted to IANA, that's it. I am done, can't never change it? I am sure lots of people are going to line up to submit their favorite type to the IANA. No more Churn, no uncertainty, Yes We Can.
Now the piece de resistance.
they, rather than the resources, maintain application state. Resource representations contain hyperlinks to help applications know how to perform application state transitions.
Yes, the very question you set out to answer, here it is. Since they contain "hyperlinks" you are done, of course, the consumer naturally speaking knows what these hyperlinks are. Makes sense, ...not. We went over and over and over this question and you write a new article to say the same erroneous statement that even the REST community acknowledges.
An application looking for information about a given employee need only follow the relevant hyperlinks using data and metadata within the representation as a guide.
How can you be sure that this is a link of such kind. How do you know it is a series of employees? How do you know a link is a contract? a benefit sheet?
What a waste of time, don't you think we have better things to do? I think by this time even Roy might the tired to ear the kind of things you write. You are actually taking a great idea: the architecture of the Web (as it was originally designed) and trashing it trying to apply to things it was never designed for and it can't handle.