☁ī¸Data Provider API Design

Conektto is one of very few platforms that enables product managers to connect their data source and build APIs easily without knowledge of complex JSON or YAML.

Conektto supports most of the commonly used relational database like SQL Server, Postgres and MySQL.

With Conektto's design studio, you can securely connect to your database server hosted on cloud or a VM with external IP, scan schema, order and sequence, make your entities available as drag/drop into the design studio.

Before you design, make sure to:

  1. Define the purpose and scope of the API: Determine the specific data or functionality that the API will provide and how it will be used.

  2. Identify the data sources: Determine where the data will come from and how it will be collected. Identify host credentials and/or SSL certificates for connecting to the database.

  3. Define the API structure and endpoint: Decide on the structure of the API, including the endpoint and the data fields that will be provided.

  4. Validate and define business logic: relationships/joins and filter conditions

  5. Publish the API documentation: Publish the API design that generates Open API spec, Java Spring boot code, .NET EF code, Apgiee endpoint, API Test workspace, and the ability to push to your GitHub workspace.

  6. Test the API: Test the API to ensure that it functions as expected and that the data is accurate.

  7. Release the API to the public or specific users: Make the API available for use by the intended audience.

Create API Project

Connect Database

Select Database Server Type, and provide host credentials for the desired database under design. You may also choose to connect to your database through SSL. You are required to upload your SSL certificates if you choose to do so. Click "Test" to test the database connection. If you have trouble in connecting the database, check "Support" section for additional details.

Invite Collaborators

APIs are no good designed, built or tested in silos. Invite your desired users or stakeholders that you would like to share the API Design project by providing their email id. The respective users will get an email with a link for collaboration.

Examine your data tables, columns, and all entities

Create custom parameters

Create your API contracts - Rest endpoints, Operations, and payload structure

Resource is the primary data representation. Having a consistent and robust REST resource naming strategy – will prove one of the best design decisions for consumability, maintenanbility, avoid API sprawl and API lineage.

A resource can be a singleton or a collection.

URI = resources + Path

For example, “accounts” is a collection resource and “account” is a singleton resource (in a customer domain).

Similarly, a singleton resource “department” inside the path resource “departments” can be identified as follows: “/accounts/{accountId}/departments/{departmentId}“. REST APIs use Uniform Resource Identifiers (URIs) to address resources. Product Managers and API designers should consider creating URIs that convey a REST API’s resource model to the end users or consumers of the API. When resources are named well, it makes the API intuitive, aligns with product strategy and easy to use.

HTTP Method / Operations

REST APIs enable product managers and API teams to build web applications having all possible CRUD (create, retrieve, update, delete) operations.

REST guidelines suggest using a specific HTTP method on a particular type of call made to the server (though technically it is possible to violate this guideline, yet it is highly discouraged).

To simplify it:

GET - to retrieve data and not for making changes to state

POST - to create new subordinate resources, e.g., a file is subordinate to a directory containing it or a row is subordinate to a database table.

PUT - to update an existing resource (if the resource does not exist, then API may decide to create a new resource or not).

DELETE - to delete a resource or data from the collections

Examine Schema and Simulate payload

Inspect the operations pre-loaded from the Schema and examine for correctness and completeness of RestAPI operations and contracts.

Pre-Publish: Validations and Mapping

After confirming the contracts, click "Publish"

Publish action prepares your API contracts, schema and entities selected for validation against OpenAPI standards as well as mapping complex business logic.

Conektto assures thorough validation of API standards. The following are various levels of validations if not addressed, your publish would fail:

  1. Naming conventions

  2. Descriptions, optional and mandatory parameters

  3. Correctness of Operations and components

  4. Completeness of Operations Status codes

  5. Bare minimum structure of a RestAPI contract (Header, Request Body, Response Body)

Last updated