If you are a good SOA believer, you will have a set of lovely services that are being used internally by your applications, and perhaps even by your commercial web applications, say via REST. It will have dawned on you that your services are already public, being accessible over HTTP, and may have even discovered some enterprising customers have benefited from this fact by writing little client applications. You think that perhaps it is time to go public, and produce an Amazon or Google style Public API for your business.
So what do you do? First you need to take stock.
Why do you want to do this? What is the business case?
Is your API suitable for making public i.e. is it well-designed, consistent, abstract, versioned, secure, monitored, documented, and adequate in capacity, availability and management terms?
Do you want to charge customers for this API? What about 3rd parties who may want to leverage your API for their own customers?
A decent API must:
- Provide value
- Be simple and flexible
- Must be managed and secure
- Must be supported
- Must have a business model and plan
A bad API:
- Has poor error handling
- Ignores HTTP rules
- Exposes the raw underlying data model
- Has a complex security model
- Has unexpected and undocumented releases
- Proves a poor developer experience
- Expects that any services “give” you a great API
- Assumes that if you build it they will come
- Provides inadequate support
- Is poorly documented