API Do's and Don'ts

APIs developed on digit follow certain conventions and principles. The aim of this document is to provide some do’s and don’ts while following those principles

• Always define the Yaml for your APIs as the first thing using Open API 3 Standard (https://swagger.io/specification/)

• APIs path should be standardised as follows:

  • /{service}/{entity}/{version}/_create: This endpoint should be used to create the entity

  • /{service}/{entity}/{version}/_update: This endpoint should be used to edit a entity which is already existing

  • /{service}/{entity}/{version}/_search: This endpoint should be used to provide search on the entity based on certain criteria

  • /{service}/{entity}/{version}/_count: This endpoint should be provided to give count of entities that match a given search criteria

• Always use POST for each of the endpoints

• Take most search parameters in POST body only

• If query params for search needs to be supported then make sure to have same parameters in POST body also and POST body should take priority over query params

• Provide additionalDetails objects for _create and _update APIs so that custom requirements can use these fields

• Each API should have a RequestInfo object in request body at the top level

• Each API should have a ResponseInfo object in response body at the top level

• Mandatory fields should be minimum for the APIs.

• minLength and maxLength should be defined for each attribute

• Read only fields should be called out

• Use common models already available in the platform in your APIs. Ex - 

  • Address

  • User(Citizen or Employee or Owner)

  • Role

  • AuditDetails

  • ErrorRes (Response sent in case of errors)

  • TODO: Add all the models here

• For receiving files in an API, don’t use binary file data. Instead accept the file store ids

• If there is only one file to be uploaded and no persistence is needed, and no additional json data is to be posted, you can consider using direct file upload instead of using filestore id