Another one: if you have an API that provides historical metrics for something, allow the user to query the start and end date range for those metrics. Otherwise, people may hit your API for metrics that don’t exist for that date range.
To clarify, this article seems to be mostly about APIs documentation. (And quite interesting at that.)
As to APIs themselves, I recently learned about https://aip.dev, and found it an extremely valuable set of good practices for designing APIs. Based on my experience, I see them as preemptively providing solutions for many problems you won’t even know you have until it’s too late. Highly recommended!
Good list. I would also add:
Another one: if you have an API that provides historical metrics for something, allow the user to query the start and end date range for those metrics. Otherwise, people may hit your API for metrics that don’t exist for that date range.
Have a good strategy for evolution, deprecation, and backward and forward (in)compatibility.
@eduardo, edmz.org’s certificate expired.
To clarify, this article seems to be mostly about APIs documentation. (And quite interesting at that.)
As to APIs themselves, I recently learned about https://aip.dev, and found it an extremely valuable set of good practices for designing APIs. Based on my experience, I see them as preemptively providing solutions for many problems you won’t even know you have until it’s too late. Highly recommended!