Remembering the Future

Nothing in REST requires or precludes an equivalent to WSDL. However, nothing in WSDL today models the interaction that is typical of WSDL itself: "at this address is a document of a given type. If you GET it, you will find a strongly typed description of another resource (endpoint)". Anybody with experience in database design will tell you that it makes sense to focus a lot of energy on optimizing reads. The web does this well. Other principles that apply: all persistent resources have identifiers. No implicit state. Posted by Sam Ruby It's interesting to note that REST instances are virtually all data-driven. The battle for the future of web services, and scaling thereof, is based on the long debated issue of data-driven systems vs. behavior-driven systems. Posted by Ken MacLeod Yes, REST is an architecture, not a particular tool, but the fact is that the current crop of tools for HTTP (and thereby, REST, at least for Internet apps) suck, and actively encourage people to write Web applications that don't leverage the Web architecture. . . . P.S. - I do agree that it's behaviour vs.data; it's still difficult for Web services people to think in terms of representations of state. Posted by Mark Nottingham Hang on, I'm a REST proponent and a SOAP proponent, so be careful when pigeon-holing. As long as you don't put methods in the SOAP body - which I don't do - I'm quite happy. What's that you say, that's document style SOAP? Well, goodie. Now assign a URI to the thing whose state is represented by that document and we're done; instant Web. . . . Yes, I'm a big SOAP fan. Just not a Web services fan. . . . And here's something to knock your socks off; when used propertly, it actually makes HTTP more RESTful (specifcally, more self-descriptive)! Yes, you heard me right. Ponder this; if you "transport a purchase order" (the paper kind) to a paper shredding service, are you asking them to shred the order, or asking them to fulfill it? Posted by Mark Baker The reason HTTP is involved in REST is because I had to shrink and redesign HTTP/1.0 to match those features that were actually interoperable in 1994, which turned out to be the core of the REST model (it was called the HTTP object model at the time) and that was carried forward into designing the extensions for HTTP/1.1. Thus, the two are only intertwined to the extent that REST is based on the parts of HTTP that worked best. . . . Why is there no WSDL for REST? Because HTML is the WSDL for REST, often supplemented by less understandable choreography mechanisms (e.g., javascript). That usually doesn't sit well with most "real" application designers, but the fact of the matter is that this combination is just as powerful (albeit more ugly) as any other language for informing clients how to interact with services. We could obviously come up with better representation languages (e.g., XML) and better client-side behavior definition languages, but most such efforts were killed by the Java PR machine. Besides, the best services are those for which interaction is an obvious process of getting from the application state you are in to the state where you want to be, and that can be accomplished simply by defining decent data types for the representations. I don't buy the argument that programmers benefit from a Web Services toolkit. Such things do not build applications -- at most they automate the production of security holes. Getting two components to communicate is a trivial process that can be accomplished using any number of toolkits (including the libwww ones). The difficult part is deciding what to communicate, when to communicate it, in what granularity, and how to deal with partial failure conditions when they occur. These are fundamental problems of data transfer and application state. . . . For the same reason, it would be foolish to use REST as the design for implementing a system consisting primarily of control-based messages. Those systems deserve an architectural style that optimizes for small messages with many interactions. Architectures that try to be all things to all applications don't do anything well. . . . it is less complex to describe data than it is to describe all of the application-dependent control interfaces that might be applied to data. It is a design trade-off of simplicity+evolvability versus specificity+efficiency. I claim that the former is better for multi-organizational systems like the Internet, but feel free to disagree. . . . Again, the key thing to understand is that the value of the Web as a whole increases each time a new resource is made available to it. The systems that make use of that network effect gain in value as the Web gains in value, leaving behind those systems that remain isolated in a closed application world. Therefore, an architectural style that places emphasis on the identification and creation of resources, rather than invisible session state, is more appropriate for the Web. Posted by: Roy T. Fielding

# posted by Guy : 7:46 AM