Web Services and APIs: A Matter of Etiquette…

First things first, what are web services and API’s? According to TutorialsPoint, “a web service is any piece of software that makes itself available over the internet and uses a standardized XML messaging system. XML is used to encode all communications to a web service. For example, a client invokes a web service by sending an XML message, then waits for a corresponding XML response.”

Now lets us have a brief definition of API’s (Application Programming Interface), according to Google: “a set of functions and procedures that allow the creation of applications which access the features or data of an operating system, application, or other service.”

So basically, these are the access points which our app, mobile or web, contact to retrieve the data we ask for. Most users don’t know about them or don’t really comprehend their importance or how they are constructed. They are not supposed to. But APS (Application Programming Services) are a multibillion euro industry that drive not only applications for the masses but critical infrastructure in sectors such as finance, health and others. Behind them lies the business logic of how data are accessed and manipulated in order to be consumed by apps in a scalable and “cheap” way.

Over the years, web services have evolved under many names such as SOAP and REST. Since the scope of this article is not to unfold the history of the Internet, which is closely related to the history of web services, we will examine the most recent and common type we nowadays come across, the RESTfull web services.

REST

Rest is an acronym for Representational State Transfer. The protocol was defined by Roy Thomas Fielding in his PhD dissertation in 2000. Since web services architectures are designed to serve over the Internet communications, they have to be fast, reliable and able to scale. They therefore have to be characterized by a few properties:

1. Performance
2. Scalability
3. Simplicity
4. Modifiability
5. Visibility
6. Portability
7. Reliability

In order -for us- to have a unified way of communication in respect to the protocol, some constraints have to be applied. These are:

1. A uniform interface which separates clients from servers
2. Stateless: The client–server communication is further constrained by the fact that no client context is stored on the server between requests. Each request from any client contains all the information necessary to service the request, and the session state is held by the client.
3. Cacheable - clients and intermediaries can cache responses
4. Layered system. A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way.
5. Code on demand. Servers can temporarily extend or customize the functionality of a client by the transfer of executable code.
6. Identification of resources. Individual resources are identified in requests, for example using URIs in web-based REST systems

These constraints ensure that we have a defined set of rules to request and receive data. And this ties well with formatting, since the data exchanged have a specific format. When we request data from a web service we make a standard HTTP request with a method (e.g. POST, GET etc.), http headers and of course, parameters. The response may vary. XML and JSON are the dominant formats with JSON being the industry standard.

Data are sensitive and more than often, quote expensive. In the infamous words of Gordon Gekko “The most valuable commodity I know of is information.”

We need to ensure we always treat this commodity with the respect foreseen by following the right protocols, constrains and rules. It’s the web’s equivalent to good manners.

Please share your thoughts and check out Publisto's website to learn more about us and to contact our team.

Picture Credit: Igor Stevanovic