Please check out Vanick Digital's blogs and other insights centered around our offerings: API Adoption & Consumption, Building Your API Practice, and API Technology & Delivery.
In a previous blog post, How to shift your APIs perspective from Systems to Consumers, I went through a case study for a customer who was learning to create API products instead of RESTful integrations. The article focused on how to design swagger definitions for APIs that solve consumer problems and are easy for API consumers to self-service understand, test and requisition.
You are using nouns and verbs correctly. You are delivering JSON payloads. So why is your service not considered an API? This article uses a customer use case to illustrate the difference between a technically compliant REST service and an API.
An effective API program rests on the bedrock of a solid reference architecture. This architecture enables the agile, reliable, performance, and secure delivery of APIs to your developers. However, software tools aren’t the whole story. Let Vanick Digital show you what tools you need to unlock the value of APIs.
Practical application of API productization requires a convergence of business and technology practices. But productization is not a natural concept for technologists and APIs are not well-understood by business product leaders. What are some approaches for bridging the divide?
Team autonomy is recognized as an important driver of delivery agility. Adoption of API productization concepts can dramatically decrease the need for cross-team collaboration by establishing clear boundaries around both solutions and teams.