API Design-first Article #306
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for bump-content-hub ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Comment on lines
112
to
119
| 1. **Readable by humans and machines**: The YAML/JSON format means it's clear for developers and allows for API design reviews / governance with teams that don't have to read multiple programming languages. | ||
| 2. **Interactive docs**: API Documentation generators like Bump.sh turn OpenAPI documents into interactive documentation, showing off parameters and examples, so clients can quickly and easily work with the API. | ||
| 3. **Mock servers**: Tools like Microcks and Wiretap can use the OpenAPI document to simulate the API, allowing parallel development of API and client applications, and allowing feedback to come in early and often. | ||
| 4. **Server-side Validation**: Instead of rewriting all of your validation logic in docs and code, you can use the OPenAPI document to power your application, making absolute certain the the documentation matches the implementation and reducing time spent writing code. | ||
| 5. **Contract Testing**: Use automated tools to probe your API implementation based off the OpenAPI document, and add assertions to existing test suites saying "does this response match what it says in OpenAPI", further ensuring the two are in agreement and saving time writing complicated contract testing by hand. | ||
| 6. **Code generation**: Many tools generate client libraries or server stubs directly from an OpenAPI document, saving loads of time. | ||
| 7. **API Style Guides**: Style guides are hard to enforce against code, developers need to check them manually, but with OpenAPI you can enforce standards on the API from the very first endpoint that is described. | ||
|
|
There was a problem hiding this comment.
This is a great section! I would add as many links as possible to our existing guides.
|
Thanks @philsturgeon ! It needed an update indeed. I would love if we can still make it as "agnostic" as possible (not stick to only OpenAPI). Also, it would be great to give guidance on a good API Design-first process, such as James' ADDR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@ChristopheDujarric the previous guide was good, but it conflated API Design-first and API-first design.
One of the most confusing things in the world of APIs is that these are two fundamentally different concepts...
I have focused entirely on API Design-first here, but would be happy to take a quick stab at what API-first means for the sake of SEO and telling a complete story. It could be a paragraph.
Other than that, this could definitely be better, go in deeper, have more diagrams, etc. Just wanted to fire it over as I'm on 4 hours with it already and want to make sure I get the right direction.