Comment API Design Decisions

The API design for a service not only depends on the organization's requirements and the services they provide, but it also depends on the internal details of the system's overall architecture. These decisions further pave the way to adopt a specific API architecture style to direct the communication between the clients and back-end services. In the following section, we'll discuss the detailed working of the comment system and the interaction between various components, which enable us to make some design decisions before embarking on the design problem.

Design overview

The following figure demonstrates how a comment system works. All client requests are passed through the API gateway and fan out to multiple back-end services. Upon receiving a comment for a post, the back-end server sets various attributes for the comment, appends it to the relevant post, and stores it in the database. Other requests, such as updating or deleting a comment, are handled similarly.

For brevity, we assume that our comment service offers only textual content as part of the comment. The following table describes some of the essential components involved in the design of the comment service.

Workflow

Let's go over how all the components involved in the comment service interact with each other to perform an operation requested by a client.

The client-initiated requests are passed through the API gateway. The API gateway performs operations relevant to identity and access management—whether to allow the request for further processing or not. Upon successful verification, the user can perform more operations, such as creating, retrieving, editing, or deleting a comment.

The API gateway directs the requests to the comment service. Whenever a request for a comment is received, this service further consults with the other services, the user and the posts service, to ...