-
Notifications
You must be signed in to change notification settings - Fork 4
API Linting In General
In the general section of this wiki we would like to provide some background why we have decided to use automated API quality assurance and what benefits come along with this approach.
After developing API´s for quite a while, every API developer shall come in touch with questions like:
- Why does every developer team in our company is having a different understanding how HTTP API´s shall look like?
- What are good API best practices in general?
- How can I integrate automated API quality assurance in my dev process stages in just a couple of minutes?
- Is there maybe more than just one generic "HTTP API" type in our company? Do we need to have a more API consumer and API purpose centric definition of API types?
- How can we implement all this in a developer centric process?
If yes -> just continue reading, otherwise TLDR...
We as SchwarzIT believe that there is more than just one generic "HTTP API" type. Like many other companies we do have application development in the direction of internal and external (Internet) usage, partially just satisfying one consumers (e.g. WebApp, MobileApp) data interest at a time with special purpose API´s, partially satisfying more than one consumers data interest with a more generic structure of the HTTP API. And of cause, we have to respect reality - there is a lot of important legacy API´s not fitting in one of the 2 mentioned types.
- Consumers: >1
- Purpose: generic
- Consumers: 1
- Purpose: special
- Consumers: 1 / >1
- Purpose: special / generic
API Linting itself shall be usable as intuitive as possible for every