BEST: Simple web service alternatives to SOAP, XML and REST

While SOAP and REST based web and integration services are ideal for organizations that are flush with racks of servers and blessed with an army talented software developers, a good enterprise architect understands that for those companies that are not blessed with an endless supply of resources that there are simpler, more effective ways to create programmable interfaces and APIs that sufficiently permit access to legacy, web-based, HTTP services.

There is no reason why traditional technologies can't support the needs of even the most modern, mobile devices.

Java is not perfect. SOAP is not perfect. REST is not perfect. Like any technology, there are times when SOAP can be used with impunity, and there are other times when the need exists to look elsewhere to better serve the needs of a given project.

Don't fix what isn't broken

It is a common plague for modern IT shops to embark on a project to provide an all encompassing  REST based infrastructure or set of SOA based components to service  the front-end of even the simplest applications. Hired hands who are brought in to fix the mess created by overcomplicating simple solutions watch in stunned dismay as entire infrastructures are ripped-up just so folks can use the latest REST or SOAP based standards. Far too many projects go forward and spend lavishly to do little more than fix things that were never broken in the first place. New isn't always better, and wasteful endeavors to fix things that are not broken work to emphasize the importance of respecting the work of previous generations of developers.

Undoubtedly, as the demand for mobilized application support increases, the need to quickly host cost-effective, legacy-integrated web services, is becoming more important every day. But there is no reason why traditional technologies can't support the needs of even the most modern, mobile devices, especially when the vast majority of invocations need only support HTTP GET requests, and potentially an HTTP POST request for form handling.

Choosing the right technology for the job

Any tenured resource knows that when bandwidth is not an issues and metadata overhead is necessary to formally define services, that SOAP is best. There are also times when a more efficient encoding with an implicit endpoint CRUD strategy makes REST a better choice. But for the majority of what the planet wants to do with their front ends, be it PHP, JSP, ASP, or legacy CGI fulfillment technologies, there has always been a far more simple, efficient, and cost effective alternative to SOAP and REST. That alternative is to simply encapsulate those 20-something year-old  GET and POST based web services and data bindings and create an API to that does nothing more than re-use traditional HTTP endpoints. In an upcoming set of tips and tutorials, we will be demonstrating just how easily that can be done.

What's the worst example of over-engineering a simple solution you have ever encountered? Let us know.