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.
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.
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.