Remember the heyday of Web services, when we were always just one specification away from perfect interoperability? Ultimately, that towering stack of protocols collapsed under its own weight. SOAP and XML generally are ridiculously verbose protocols that began with a commitment to simplicity and gave way to mind-numbing levels of complexity. Add to that the service repository mess: UDDI died an ignominious death, and OASIS's S-RAMP committee can't even create a website that isn't all broken links.
[ Also on InfoWorld: 9 app dev projects you should cancel in 2013. | Download InfoWorld's PDF of tips and trends programmers need to know in our Developers' Survival Guide. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
Brought to you by the Internet
Brought to you by the InternetWhat does this look like? Consider your Order/Line items example.
Save or update the order:
"streetAddress": "345 West Main St, Suite 201",
Replace the line items of the order:
Delete the order:
Get the order:
Security in a RESTful world
As Oracle will tell you, security isn't really important, and the best way to handle it is by sticking your head in the sand and making people wonder if you are the corporate equivalent to Grandpa from "The Simpsons." However, if you're one of those young whippersnappers who care about preventing other people from stealing your stuff, you'll want to secure those RESTful Web services. Security is simple with RESTful Web services. Since complexity tends to result in complex breakages, this is a good thing ... mostly.
For RESTful Web services you generally use HTTPS and basic authentication.
Not quite nirvana
I admit that I've always had a nearly irrational hatred for XML that comes from having to type angle brackets; on an American keyboard, it's a recipe for a hand cramp if you're a touch-typist. That said, DNS tells us where the ordering system is. It isn't particularly good for telling us that all orders go under "Order" and not "order" or "Orders" or "orders."
We can have a corporate convention and publish documentation, but this isn't exactly an Internet-wide phenomenon. You can use WSDLs -- or now their lighter-weight (but still big) wall of XML cousins, WADLs -- but it quickly leads us down the path of "where is my service registry?" to store the WADLs. There also isn't much of a convention for "where" to get the WADL relative to the service. Nothing good will come from shoving more stuff into DNS txt records, and if we end up with a WADL for DNS over HTTP, then happy hipsters will bring about the meta-apocalypse.
When it comes to security, the basic authentication's point-to-point may not be adequate to the task. Systems don't just do things for the right client; sometimes they facilitate requests on behalf of that client on other systems. In a robust SOA environment, these kinds of "on behalf of" activities and other kinds of nontrivial security arrangements are more commonplace.
Choose both?It is possible with many modern frameworks to deploy a service with both JSON and XML endpoints. It's somewhat difficult, but not impossible, to be RESTful and SOAP-y at the same time. Increasingly, companies have to expose services as JSON for their myriad of devices. Some companies deploy front ends as REST-y JSON, then have another tier of XML sauce.
A few years ago all remotely accessible services were by default deployed as SOAP Web services because that was assumed to be the future. The AJAX mobile revolution changed all of that. Now, because you are probably developing services for both Web and mobile devices, and you may be developing services for your wider enterprise or the Internet, why not just do REST and forget the SOAP monster?
This article, "Web services are dead -- long live REST," was originally published at InfoWorld.com. Keep up on the latest developments in application development at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
This story, "Web services are dead -- long live REST" was originally published by InfoWorld.