Web APIs - A timeline of web services (Part IV)

Welcome to the world of lambdas and serverless functions

Microservices offer a highly-focused (single responsibility), low latency, auto-scaling web services. We could orchestrate these services as per our need. Developers look at microservices in not only a synchronous way but also in an asynchronous way.

One could tie an event-driven pattern using CQRS back-ending the microservices. A neatly designed CQRS can gracefully decouple read data to the write data. (That's for another post though)

Be it vert.x, sinatra or any other platform, we define services with the granularity we need.

Recently, for building a chat bot, I started exploring AWS lambda functions. Chat bot APIs need a very structured handling of states and transitions. So such APIs need to use session and context linking/sequencing to provide data interactively. I have been using nodejs serverless for building these APIs. Here's a quick guide to how serverless environment can be configured to make our services discoverable, secure and scalable.

I have to tell you that the world of APIs ever since I started my career always interested me. There is a choice of stack and a configuration that fits each of the clients needs in different ways.  An enterprise grade banking API needs are very different from that of a smart home automation IoT API.

Web APIs - A timeline of web services (Part III)

RESTFul architecture re-imagines Web Service integration in a more http-oriented way. This kindled interest in the API designers & practitioners to fill in some gaps in standards-based metadata overload, security and client integration.

In RESTful Architecture, objects are modelled as resources (actors) as opposed to verbs/actions. It is typical in this mode of communication for the client to access and explore a resource before editing/modifying the data. For example, one GETs a user by searching with the id or name. Checks the address and modifies a field let's say street and PUTs. While the objects depend on the application/business/domain, the http actions are universal! Clients don't need to refer to getUser, editUser or deleteUser separately. Add attachment handling, header management, content type management, caching and metadata handling to this, it is a great recipe of APIs. No wonder most services are at peace (RESTful) these days.

The ease of REST services aligned naturally with the integration to web layers because of it's closeness to HTTP.

Anyone thinking swagger or apiary?

All Web Service / API Developers run into a common problem.
How granular should my service be? Do I have a mammoth service that does every possible activity at just 1 end-point? Or... do I do finely grained single responsibility super-responsive services that I can tie up as needed?

Continued in the next part...

(Please let me know your feedback in the comments.)