Hello All!

As you can notice, in previous maze post I had used REST/JSON API to communicate server Java results to HTML/Javascript client. It is basically the structure I chosen to explain my examples: Java server holds high cpu load tasks, Javascript just represents it, and communication is done with REST/JSON APIs.

I had noticed that there is no explanation in my posts of how to create this APIs, and why, just the code in the repository itself. In fact, once understood, there’s no real difficult to implement any kind of webservice in any common language. So, I will realize this explanation & examples in this and next post.

A little history about WS in general: as computer science, and computer networks raise, communication protocols against each node where begin to be studied and standardized: begin to appear communication codification standards as EBCDIC (~60s), from IBM, or X.21 (~70s). At 70s as well appeared TCP/IP protocol, which will be the most successful. Appear then over TCP/IP, between others, ISO8583 (approx. 80s) financial protocol, that personally I think it’s really well-designed, and its so flexible & powerful that allows any kind of sales operation: knowing it’s efficiency its not strange to see first 80s was the exploding of yuppie epoch.  Note that most of them are still used in big companies: in my current job, where we interact with big telephony companies around the world, we had until recently a X.21 hardware processor. As well, I had used EBCDIC codification to consume services (note that not yet ‘web’ services) for countries as Brazil, Argentina and in Spain itself, and as well we are consuming a big quantity of services in ISO8583, or its XML representation.

Appears as well HTTP protocol, though to send massive text & formatting, basis of actual internet communication. So, then, at 90s, HTTP was wide spread, basically because was the way to serve web pages, in growing world wide web internet, to client ‘browsers’, allowing transmitting images, texts, media, and later, with Javascript, flash, java plugins, etc, interact with final user, from any server to any customer machine. But there was as well a not-so-visible feature: servers could use that protocol, HTTP, to publish mechanism to automatize communications between machines. This is the birth of actual web services: allowing backend calls to servers for any kind of purpose, over HTTP, usually not visible to final user. At 1990s-2000s still there was no very big spread of them, or at least popularity, as the one kind of machines that need interacting communication were just personal computers (as well cash-drawers, but which still use ISO8583 or native protocols), and any needed interaction between that machines were commonly solved using ‘visible’ internet, or priors tcp/ip protocols. Note that general network speed & cost was not the actual one, and sending a direct TCP/IP pattern, well-designed, was smaller & cheaper than any XML sent, more verbose, but with more bytes by packet: to create a personal & specific TCP/IP protocol was the norm.

When appear internet-connected mobile devices in scene, with its full interaction with servers not just to show web pages, and network speed began to grow and cost began to decline, use of WS over HTTP began to grow and began to be standardized, first just as XML representations, later with SOAP standard (1998). SOAP standard was, and its right now, extensively used. It implements WSDL, that it’s a concrete definition of the functions, kind of responses, kind of parameters, etc, that got a SOAP service. This is very useful for a programmer, so acts as a prototype and gives a lot of information about what to implement. As well, a lot of languages develop their own features to consume and publish this kind of WS in an automatic way, generating, in OOP, needed class definition, just getting & parsing WSDL file from online service.

SOAP protocol had been really successful, but got its own problems. First, the WSDL itself can act as a contract, and so, when applied, it constraint flexibility needed in this engineering. There was a performance issue as well: an XML could be really big, just by its design, as each tag will be closed with same tag name. That means size will be doubled, but not on significant information (values on each tag) but just in message structure, just for design. As well, was based in RPC architecture, and it can be considered an ‘external library’ for coding, but not more.

Appeared then REST architecture definition (about 2000), against the RPC architecture. Note the second was just calling remote functions, as one can do programming, and act accord, while the first defines a way to structure an online site as a dynamic repository for information & functions, using as well extensively the previous defined HTTP verbs GET, PUT, POST, DELETE. This allows to create a whole ‘non-visible’ functional ecosystem, that can be used remotely.

With REST, although you can define an XML API, the usual thing is to use a JSON representation for communication, calling them REST/JSON API. Note that SOAP comes from XML definition of a web page, in HTML, first, as JSON comes later from Javascript’ spreading: JSON implementation as communication protocol benefits then from REST architecture specification, did later that SOAP standard definition.

So, here we are right now: REST/JSON is being the most demanded API definition nowadays, leaving to deprecation SOAP and antique direct TCP/IP or HTTP communication protocols. As well, REST/JSON learn from its ancestors, begin smaller each transferred package & more flexible in its definition. It is easier to implement as client (there no need of namespaces, SOAPAction header, no need to keep useless tags, etc…just using the correct HTTP verb and send the resumed data in JSON payload, than can be checked with a fast curl) and as server (lots of frameworks had appeared in any level language). There are, of course, lacks on its design  (for example, the WSDL definition had been really useful in a lot of cases for me), and there as well not-so-correct fullrest implementations that gives to a coder real headaches, while SOAP, being more strict about its definition, doesn’t allow this kind of variations. Anyway, as you can see in next post, solutions had been deployed for that.

That’s all! Sorry about this heavy post but I feel in duty to explain a little about. At next post we will generate JAX-RS & explain a little Springboot ecosystem. As always, explanations comes just from my own experience & learning. If anybody wants to correct me in any point, feel free to do it.