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.
It’s all too easy to think of your API process as a single entity with a single set of security concerns. But just because you’ve made all the right security decisions for one component doesn’t mean your API’s are safe from vulnerabilities lurking where you least expect them.
Vanick Digital discusses two custom API modules that we have developed for our customers.
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?