Planning the RealWorld API
As with every API, you will need to go through the typical stages of development.
Determining requirements
It is essential to gather and understand requirements for endpoints to have defined use cases. The RealWorld App project has strict requirements that any implementation must follow. The first step is understanding the API definition provided in the RealWorld project, including each endpoint’s requests and responses.
We’ve used the Postman collection provided in the RealWorld API project to exchange data with Conduit to understand the existing functionalities clearly. However, while analyzing the functionalities, we noticed incompatibility among the documents from RealWorld. Although RealWorld API provides API documentation alongside the Postman collection, some parameters and responses were not the same across all documentation.
API architecture
API documentation comprises mainly planning, designing, and reviewing the construction of APIs and enforcing developer guidelines. We’ve followed the same architecture provided in the RealWorld swagger 2.0 JSON API file.
Linx immediately creates all the associated operations under the RESTHost plugin when the swagger definition is imported.

API configuration and security
API Configuration is vital in implementing data integrity and security, endpoints, responses, queries, and parameters. The API configurations must be identical to Conduit to build an API compatible with the existing front end. The following basic configurations of REST APIs must be the same as the RealWorld API:
-
- Security and Authentication
- Methods (Endpoints, query values, body, etc.) and parameters (supported data formats)
- Handling response data (HTTP Status Codes, responses).
Open API supports multiple authentications and authorization schemes specified with the “security scheme” component. For example, the RealWorld API uses API keys with JWT token for authorization.
Linx provides built-in functions to generate and verify JWT Tokens, facilitating the authentication scheme’s implementation.

Database design and architecture
Storing and pulling data from a database to exchange with an API can be challenging. So we’ve decided to host our data source for data persistence. Linx has plugins that allow connection with various databases. Since it is freely available, MySQL was the best option as a database source. It is preferred to have the database hosted on a remote server in the cloud to limit the extent of a cyber attack by adding an extra layer of security. Once we had finalized the database architecture, we were ready to move to the next step.