New REST API feature

New REST API feature

SDK implementation is part of the feature opportunity. The new functionality should be covered by tests and reviewed by the maintainers (ideally primary contact) defined in the CODEOWNERS file in the SDK repo.

Ideal process of the submission

Let's image a new entity in Kontent - let's call it a "note". As a part of the opportunity, the development team wants to introduce new endpoints connected to this entity to Delivery REST API (to allow fetching user's notes) and adjust one other endpoint connected to the new entity - user entity will have a list of notes' IDs in the response. The ideal workflow would look like this:

• Development team decide to implement new opportunity
• Dev team contact the maintainers of the respective SDKs. In this case .NET and JS SDKs.
  • They introduce the idea to the maintainer to get early feedback and information about SDK implementation.
• Once the feature is defined and the REST API contract is known (not implemented), the development team submits the GitHub issue based on feature request template describing the new feature to the respective SDK repositories listed in develop apps overview (such as this one for .NET and JS). You can split the functionality into logical parts as separate issues - it is up to maintainer<->dev team agreement.
  • For primary stacks - Javascript and .NET - assigns issue to dev team members -> see Implementation checklist for scope.
• After the implementation part is done (implemented and successfully reviewed) - the maintainer will handle the release process.

Implementation checklist

Based on https://github.com/Kentico/repo-template/blob/master/.github/PULL_REQUEST_TEMPLATE.md

• Code follows coding conventions held in this repo
  • For .NET repositories the standard Microsoft coding conventions appies
  • Kontent specific guidelines for repositories applies
  • If there are any other repo-specific requirements - they are described in the repo's README.
• Automated tests have been added
  • Sufficient state is that happy path is covered.
    • Ideal state is to have the code fully covered (happy and unhappy path).
  • We do not test implementation of the REST API itself, it is possible to use Mocked server responses.
  • Repositories might contain tests for Documentation code samples
• Docs have been updated
  • If new functionality in REST API is being showcased in API reference
    • Create a pull request with a code sample based on the SDK you are implementing and for REST (as i.e. this pull request for REST, example for Javascript pull request)
  • Validate whether there is a need for adjusting README in respective SDK repositories
• Temporary settings (e.g. variables used during development and testing) have been reverted to defaults
  • no sensitive keys have been committed to the codebase
  • no temporary project ID is being set in the pull request

Release process

The release process consists of two steps:

1. Publishing new version on the package manager (.NET -> Nuget, node/js -> npm, ...)
2. Ensuring the proper announcement
   • New feature is described in release changelog
   • Decide whether to announce new version in product changelog/discord/newsletter