Maintaining tests for API's can become a heavy task depending on how many API's and routes you have to maintain and how often things are added.
One could also think of offshoring the testing to a dedicated company. I gave it a try and received offers which calculated a fee for each route to test.
Unfortunately, none of the companies I contacted bothered going into details what kind of tests they will deliver.

I use the API first or design first principle to outline the requirements of the API under development and do this by defining it with OpenApi specifications.
I wrote an article some time back of the tools I use to write OpenApi definitions.

Introduction

Througout this post I am describing the path it took me to specify my own REST API's (API specifications) as well as how to document them in a browasable and accessable way.

It focues on tools to simplify your work but also includes topics like mocking and linting.
A summary in git project can be found at the bottom

If you are developing REST API's for internal or external use, you will need to document it at some point. To do so, probably the best approach is to follow a given standard. Some of the goals we can achieve with this, is:

- fast starting point for new developers
- follow the same principles
- standardize and follow best practices
- save time (compared to writing your own specs)
- use tools (document, try out, test, mock, stub)