Currently many startups start to play with API Services, which stands for Application Programming Interface. It’s basically interfaces to consume services of provided by people or companies. There are some common formats used nowadays, such as SOAP (Simple Object Access Protocol) and ReST (Restfull State Transfer). Let’s first discuss the differences between those key terms for services:
| SOAP | ReST |
|---|---|
| Protocol to transfer data. | Architecture Style utilized by application architects. |
| Hard-Coupling, like a Client-Server applications. In case on any change on client or server, connection breaks. This can be compared to a desktop system, which syncs to a server. Any detail about the communication is shared and available in order to create connectivity. | Generic client connectivity, where only basic knoweldge about protocol and standardized methods are known. Additional methods don’t violate the protocol standards, but can leverage standard methods and create actions with them on your media type. The outcome is less coupling and changes can be dealt with more gracefully. Clients is supposed to enter a ReST service without knowledge of the API, except for the entry point and media type. |
When accessing services, it is necessary to provide connectivity details for authentication and authorization. Currently this can be handled by API management services such as Tibco Mashery. When using more-complex scenarios it might become of interest to provide your own authentication tokens to allow clients to authenticate to your services via other services. Image platforms such as booking.com utilizing the rates platform of hotels or air carriers. RFC 7519 of the IETF (Internet Engineering Task Force) descibes a token-based mechanism to solve this kind of issue by using Java Web Tokens (JWT).
Those tokens provide multiple elements, such as:
- Header
- Payload
- Signature
Encoded details are separated by a separator such as “.” in the example above. This reduceds overall size of the message to reduce the amount of transfered data. However, all segments are encoded one after another. Another current method is based on TweetNaCl, which forks RFC 7519.
As you can see, the outcome is similar to JWT, without separating the details in separate branches. The data is encrypted (not just encoded) using a private key. By setting a Nonce (a public shared key), consistency of the data is ensured. Any change to the Nounce will invalidate the data.
Those tokens can encrypt details such as:
- Customer name
- Contract number
- Contract runtime
- Contract conditions
As some details might be sensitive and must not be shared with platforms such as booking.com, hotels or carrier might not want to share their customer details directly with such platforms. Some details might still be required for platoforms to provide certain services, such as token renewal. This can be achieved by adding a linux timestamp as pre-fix of the Nonce. Another interesting story would be a coin, such as in block-chains, where the Nounce must be calculated. The data-power can be generated by corporations own IT infrastructure through users.
