Web services are dead -- long live REST

Once, an endless parade of Web service protocols promised to guarantee any system could talk to any other. In the end, we got much of that interoperability via simpler means

1 2 Page 2
Page 2 of 2

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.

Copyright © 2013 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a low-code development platform