This week we held our second Ask Me Anything event live on YouTube, where Keshav Vasudevan, Product Marketing Manager, and Temil Sanchez, API Sales Engineer, answered all of your burning questions about APIs and the API Economy. During the session, we covered everything from SOAP verses RESTful APIs, to OAS 3.0, to API monitoring and more. In case you missed it, we rounded up our favorite questions and answers. Check them out below!
Should I have an API monitoring strategy in place? Why?
APIs are everywhere, but that doesn’t mean that they all have the same mission critical implication. Of all of your APIs, in which environments do they have the biggest business impact? Which APIs can affect your mission critical applications? Once you know what those are, determine what the potential business loss would be if those APIs failed. If it is substantial, you should definitely have API monitoring in place.
What are some practical recommendations for making my APIs easier to consume?
APIs are meant to be usable and reusable, so it is really important for them to be easier for developers to understand. Most people think of their APIs as exposing some data and finishing the job, but in today’s economy you should be thinking of the long term. APIs are connecting different applications together and are therefore very important to your business.
We recommend thinking about the consumer perspective. If your users have trouble understanding your API, they’ll stop using it. We recommend using OAS 3.0 to help you define your APIs, and tools like Swagger to make beautiful documentation for them.
What’s the best way to get started with OpenAPI Spec 3.0?
The OpenAPI Specification is the world’s standard for defining RESTful interfaces. It defines what the API does, the resources the API exposes, and the associated requests for each of those things. It isn’t based on code, meaning anyone (humans & machines) can understand it.
Getting started is easy, as there are tons of free resources out there! The Swagger website has comprehensive documentation to help you get started. There is also a great tutorial by the API Handyman that we highly recommend. You can also find plenty of YouTube videos that will help you get started.
What are the most common protocols in the API industry, and what are their use cases?
Whether it be HTTP, SMT, or something else, all of these different protocols are the underlying layers of the architectural styles. Start by determining the use case of your APIs. For example, SMT might make sense for emails, but if you’re looking for easy integrations you’ll need to go with REST.
However, business use case isn’t the only consideration you’ll need. Ask your team what they are comfortable using before making any decisions on which protocols to use.
What are the best practices in moving towards microservices based architecture?
Microservices are on the rise! Why? Older companies that are trying to transform to digital are having a hard time maintaining their monolithic systems. Many of them are choosing to break down these large systems into smaller microservices to solve this issue. To do this effectively, you’ll want to make sure to follow good documentation, good design approaches and utilize open source tooling.
As you get started implementing microservices: 1. Identify your technology stack, 2. Identify your business taxonomy, 3. Make sure your company’s culture aligns with your long-term goals of moving to microservices
- Identify your technology stack: Make sure you are well equipped for microservices. Be able to isolate certain services and be certain that all of them expose their data through an API.
- Identify your business taxonomy: Meaning, identify your business bounds. For example, a payments service needs an accounts service, an iframe service, and an ecommerce billings service.
- Make sure your company’s culture aligns with your long-term goals: Microservices are a long-term project. Before you start, educate your team on what microservices are and the benefits.
Where is the best place to host an API?
There is no best place to host an API- it all depends on your business cases. Here are a few common scenarios:
- Let’s say your API will be consumed by 3 developers internally. In this case, just make an AWS server and share it with your team.
- If you need to move faster or don’t have time to build an AWS server, use a tool that abstracts the hosting for you, like SwaggerHub.
- Let’s say your API is public facing or partner-based. This is when you should start thinking about developer portals, where you’d house everything a developer needs to get started with your APIs. There are great tools out there for this, or you can build them yourself.
Is it really efficient to do performance and load testing on separate APIs, rather than doing it for the whole software?
The short answer: yes! You’ll want to strategically parse out your whole application so you can replicate the real usage of the system and get concise data. This way you know what failed and why, which lessens your debug process.
What is the difference between SOAP and REST? Which is better? Why?
The SOAP service used to be very rigid in order ensure users understood the messages. With that rigidness came very strong security natively. Over time, we had the need to better integrate services, which is when REST came along. REST is all about easier integrations— very simple, very straightforward. But there are also some challenges with security, which add ons like OAuth now address.
Want to know what else we talked about? Check out the full recording here: