One of the challenges that comes up when working to advance an API platform is to know "when to stop". Not all organizations need the same level of "advancement" in their programs in order to meet the needs of their API consumers. And some organizations will need to move the needle a bit farther along than most. But what does this continuum look like and how can you know when you've gone "far enough"?
What is needed is a model or measure -- a rubric -- that people can rely upon and consistently apply in order to know just how much attention should be paid to creating reliable and robust APIs and services.
Rubric: A rubric is typically an evaluation tool or set of guidelines used to promote the consistent application of learning expectations, learning objectives, or learning standards in the classroom, or to measure their attainment against a consistent set of criteria. In this case the learning experience is in the API/services domain.
A Progression of Implementation
A valuable guide for evaluating the worthiness of an implementation (API or service) is to think of a progression of implementation to traverse along a line that contains four identifiable qualities:
Effective
The solution (API/service) does the work it is intended to do. Things like sign up new users, filter the data into a report, modify the data in storage and so forth.
Available
The solution not only does what is needed, it can be accessed where it is needed. For example, if you need a local command-line app to solve your problem the API supports that. If most users will need access to the solution via a web-based interface, there is an HTML page for that, and so forth. Now the solution is both effective and available.
Scalable
The solution is reachable when it is needed. That means, no matter the time of day or the traffic load, the solution meets the needs of the consuming community. Even when lots of requests are sent through the API, it will continue to perform as expected. Now the solution is effective, available, and scalable.
Efficient
The solution is efficient. It meets all it's needs without a lot of effort, spent resources, or needless complications. That might mean it is easy to use, easy to integrate into other solutions, etc. Now the solution is effective, available, scalable, and efficient.
This EASE rubric is a dependable way to evaluate a target API or service as to whether it is meeting consumer needs.
Only Sometimes
A key thing to keep in mind is that not all solutions need to excel and all four qualities. If the API is only used internally by a single team, then it is likely that it will have only minimal scalability and efficiency. And might only need a bit of extra work in order to meet availability needs.
However, if there is an API that needs to support hundreds of simultaneous connections in order to return large data payloads, then it will be appropriate to devote added effort to make sure it is at least scalable and might need some internal work in order to increase efficiency for each data call.
Maybe Never
The lesson here is to start at the beginning (effective) and release that first. If you find you need to improve other qualities (the ASE of EASE) then address those needs when they come up. Don't assume you need to spend time on efficiency for the first release. That might just delay a production release for a quality that is not now (and may never be) needed.
Bottom Line: Use the EASE rubric to advise you on just how much effort is needed in an API or service when it is released into production
How about using this rubric to decide when to invest in updating legacy APIs to meet new governance models? Ive been working with an organisation on a two-track API governance model where new APIs are built to meet recently-introduced standards/style guides/best practices whereas existing/legacy APIs are updated by being defined using a specification file and added to the internal catalogue but otherwise left alone to avoid breaking changes, etc. any further thoughts on whether this rubric could be used to help decide when to invest in updating legacy APIs to the new standards and when to just leave them as they are?