Comments regarding plightbo’s recent anti-REST posts…

Objects vs. Resources

There is a fundamental difference between objects and resources, and it’s really important. Objects are data + behavior, whereas resources are just data [and links to other data, if you’re smart]. It’s the associated behavior that makes things scale badly. There is a world apart from objects: the semantics of the data itself are of primary importance, not the semantics of an interface to that data.

Tools

There are plenty of tools for RESTful systems … you’re just taking them for granted…

• Apache / Tomcat / Resin / JBoss
• Web-browsers
• httpclient / nogoop / URLConnection
• Log analyzers
• Sophisticated Proxies and Caches

All these tools solve very tangible problems, and have been shaken out over a long time. The tools for some other technologies seem to exist primarily to solve problems or reduce work created by the technology itself… though in some cases they do solve a higher-order problem, and are useful. WSDL is a good example: a reasonable resource/interface-description language, and, hey, it can be applied to RESTful interfaces very well.

Tools aren’t overlooked because of religion — they’re overlooked because they defocus developers from solving the real problem-at-hand rather than the details around the technology brought to bear in hopes of solving the problem at hand.

CRUD operations masked over a database

How is GET http://www.google.com/search?q=important+search+term a “simple CRUD operation thinly masked over a database”?

Or a POST that buys you a ticket on an airplane and moves you across the country?

It’s not that the operations or verbs or especially their implementation is simple. It’s that there’s a simple interface to them. REST requires a constrained interface, not a constrained implementation. In fact, it enables the implemention to grow unconstrained by a tightly-coupled interface. It’s another form of encapsulation — but of the procedural implementation, not the data. In fact, a view of the data is given primary importance.

Business tasks

You’re correct in saying that business people don’t care about the implementation details … but only until you tell them “no, we’d have to spend 6 months re-architecting the system for that.” Our job as engineers is not only to implement the currently-required functionality, but also to keep the system healthy and able to grow. They also don’t care what language we write it in [although they do from time to time], but we choose what language to write it in for a variety of time/skill-set and growth concerns. And with respect to this thread, I know which technology is available in nearly every language we would every even consider working with, and it isn’t SOAP, RMI or XML-RPC…

There are some things that require foresight, and can’t be designed for the moment; that’s why it’s called architecture, and not design. APIs are one of them, and networked APIs even more so, especially with the expectation that the system will grow very quickly.