Site Sponsors:
EasyHTTP - A simple design for Java GET / POST 
With all of the hoopla over Web Services, you would think that servicing user requests over HTTP was something new.

Well, we all have lots of experience with REST, JSON, XML, SOAP, WSDL, HTTPS, and even EDI ... but at the end of the day, it all comes down to legacies, security, and performance?

Classic Web Support

The ideals behind SOA, SOAP, & REST are crystal clear. Just as clearly, a real & current need also remains to leverage the traditional ways of providing services to our Internet Users. --Wouldn't it be great if our web services could re-use our existing web-based forms, urls, and interfaces?

Well, with EasyHTTP, they can!

Because legacies are important, EasyHTTP allows our "Web 2.0" Web Services to continue to inter-operate with our "Web 1.0" HTML Forms & Services.

Indeed, using EasyHTTP, support for classic HTTP GET / POST Forms & URLs can be integrated into your Web Service Project in an average of 3 lines of plain-old (no annotations required!) Java Code:

TextResponse response = new TextResponse();
HttpService service = new HttpService(new URL("http://localhost/test.html"), true);
if (service.get(response) == true) {

Add two more lines of code, and even creating a web service to automate the completion of an HTML fill-out form is easy:

// TEST: Rich, multi-param, POST
PostRequest request = new PostRequest();
TagValue[] array = {
new TagValue("firstname", "randall"),
new TagValue("lastname", "nagy"),
new TagValue("phone", "123-456-789"),
new TagValue("email", ""),
new TagValue("title", "geek of the week"),

// Works the same as for GET
TextResponse response = new TextResponse();
HttpService service = new HttpService(new URL("http://localhost/test.php"), false);
if (service.get(response) == true) {

(Yup: EasyHTTP makes it that simple to create a Web Service call to fill-out & pass data to your classic HTTP Forms!)

Why should we care about their legacies? Because supporting your legacies means that any existing PHP, ASP, JSP .. and even our browser-based JavaScript operations - will not have to change! (i.e. EasyHTTP could save companies who are now fixing decade-old services - HTML Forms that were never broken in the first place - millions of dollars. :)


I recently read a discussion about how using classic GET and POST parameter passing make service interfaces fragile. Yet, can we ASSUME that a 'no version identifier' is requesting our 1.0 Service? If so, then by thereafter including an official service-version field, all is fine once again.

Moreover, once we acknowledge that HTTP respects the 50-year-old need for designing in both a stdout, as well as a stderr response, most of us cannot see what in the HTTPS is wrong with continuing to use classic data-exchanging techniques. -Even arguments over using the more lean array encoding in JSON -v- XML seem moot: The classic use of & and = are as terse as it gets? -Certainly everything outside of what HTML 5 Forms can support is an exercise best described by the Pareto Principle?

Once again, if it ain't broke, why spend industry-billions trying to fix it? --Book sales??

(In other words, perhaps we all should first try to understand how things work BEFORE we try to re-invent things as small... uh ... as the Internet? (i.e. Every first-year web designer knows that HTTP Forms can have hidden fields. Why not a hidden service-version identifier, as well?))

Real World Results

Indeed, when used as a forms-injector, I was able to forms-inject over 180,000 recipes into a web-hosted, HTML Wiki tool. -The results can be seen at the Wiki Recipe Club.

But legacies are not everything. Oh sure, it is great to be 'easy to use', but what WE find easy to use, others will find just as easy to hack...


Therefore, once our service version(s) are under control, the next simple idea here is to allow us to focus more upon the transactional plumbing, than the data-exchange protocol. (i.e. While HTTP is great, modern enterprises are about a lot more than HTTP!)

Hence EXTENDING a legacy to be able to SWAP TRANSACTIONS with a "blind" HTTP Endpoint / Service is far more clandestine:

// TEST: Complex POST (ping -w- redundant GET parameters)
PostRequestTest request = new PostRequestTest();
if (, response) == false) {
if (response.isComplete() == false) {
if (response.isNull() == true) {
String[] lines = response.getResponse();

Operationally encoded, data-driven, and / or custom-encrypted (rather than clearly protocol-dependant & far too demonstrative,) transactions. (All one needs to break a cypher, after all, are enough common keywords to look for? -Put enough of those tokens in the exact same location each time, and one might as well not encrypt anything at-all?)

The Project

So without further ado about how to 'properly' encoded data, operations, and 'service contracts', here is a fast, easy way to exchange data with any HTTP Server:

Unlike Apache's wonderful HTTPCore, EasyHTTP consists of a mere handful of classes. A minimalist feature-set that will allow us to secure either our data, or our server-side operations, in any way WE feel the need to do-so.

Finally, because EasyHTTP uses far fewer classes to manage the exact same base classes used by other techniques, it doesn't get any faster than this, folks... even our installation, download, & compilation times will improve.

Easy Features

In addition to being a light, properly-encoded way to encapsulate those troublesome URL / HTTP Connections, EasyHTTP also includes a simple PHP test case:

$action = $_POST['op'];
if ($action) {
if (strcmp($action, 'test') == 0) {
echo "Success: $action - PHP POST RECEIVED.\r\n";
$action = $_GET['op'];
if ($action) {
if (strcmp($action, 'test') == 0) {
echo "Success: $action - PHP GET RECEIVED.\r\n";
echo "Test Protocol Error: PHP GET/POST 'op=test' not detected.\r\n";

So to start enjoying a significant size-decrease for your "web service" legacies, AND your leaner & meaner obfuscated HTTP Server-support Projects, simply download EasyHTTP from Sourceforge, copy test.php to the root of your localhost, then run php/


Looking back, the ideas to (1) Embrace the architectural principles of RESTfull Services, yet to (2) add version numbers to support, rather than to simply abandon our legacy web services, then to (3) encode our CRUD as PART of our operations so ANY PROTOCOL (not just HTTP/S) can pump transactions throughout our enterprise (a Security / SOAP 'thang) inspires me to create a catchy acronym to sum up such a simple, evolutionary, concept.

How about the "Business / Enterprise State Transfer"?

-You can call it BEST :-)



p.s. - The EasyHTTP jar file also includes the source code.


Add Comment
Comments are not available for this entry.