How REST plus JSON over HTTP/HTTPS won the race on interoperability
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.
Interoperability Nirvana remains out of reach. What do we have instead? We have the registry called “the freaking Internet.” Services are registered as URL handlers, and we execute against them. The XML transmission format was replaced by the format that your browser and mobile devices all learned to speak: JavaScript Object Notation. REST plus JSON over HTTP/HTTPS is the new Web services — strangely, it’s more interoperable without an explicit specification. Instead we make it work like the Internet, and DNS is your service registry.
[ 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. ]
We use JQuery/JavaScript/JSON for our UIs nowadays. We can even use Node.js for our business logic. Databases like Couchbase 2.0 and MongoDB speak JavaScript and JSON (or a direct derivative) natively. The beauty of this as an architecture is that we can drop entire layers of object binding and data transformation from our code.
Brought to you by the Internet
What does this look like? Consider your Order/Line items example.Save or update the order:
POST http://infoworld.com/example/Order/123
{
"firstName": "Andrew",
"middle": "C",
"lastName": "Oliver",
"address": {
"streetAddress": "345 West Main St, Suite 201",
"city": "Durham",
"state": "NC",
"postalCode": 27701
},
"LineItems": {
{
"type": "widget",
"sku": "123-456"
},
{
"type": "widget",
"number": "452-123"
}
}
}
Replace the line items of the order:
PUT http://infoworld/example/Order/123/LineItems
{
{
"type": "widgetTypeA",
"sku": "123-456"
},
{
"type": "widgetTypeB",
"number": "452-123"
}
}
Delete the order:
DELETE http://infoworld.com/example/Order/123
Get the order:
GET http://infoworld/example/Order/123
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.All this begs a question: In an AJAX-y world with mobile clients, what really is a front-end service instead of back end? Isn’t the JavaScript-like HTML page just a client? Frequently these “front-end services” devolve into an overblown proxy or remoting version of the GoF bridge pattern. In other words, it’s needless bloat and object transformation.
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.
