Evaluating Web Service APIs: Criteria for flexible video management
When we started thePlatform, no one else was developing a set of video management APIs that anybody could use to build an online media business. Instead, they developed user interfaces on top of proprietary systems that could only expand when developers felt like adding features. If you wanted to do your own development on top of their systems, you were out of luck.
Since then we’ve had 10 years of continuous improvement and growth in our web service APIs. Other vendors started to add web services APIs over the same period and it’s now a standard part of evaluating a video management provider: “How good are the APIs, and can they grow with us?”
Our new white paper aims to help you out with this evaluation process, offering questions and answers that we hope will be useful in helping you figure out whether a vendor’s APIs are of a caliber that will meet your needs.
You can download the white paper from our web site Solutions page, but we’d like to cover some of the top criteria here to give you an idea of where to start.
Breadth
First, APIs should be available for as much of the video management system’s functionality as possible. You’re the best judge regarding what parts of the system you need to extend to support your business, so you’ll want all your development options open.
The easiest test of an API’s breadth is to go to a management console or user interface and try to figure out whether the vendor uses their own published API. If they’re not using it, not only is that a sign that they haven’t built their system for maximum adaptability, but they can’t rely on their own code to support their product.
Literally everything you can do with thePlatform’s systems—automating workflow, integrating with other technologies, adding, editing, and deleting metadata, etc.—is exposed through our APIs. It’s not possible for a feature to appear in the mpx without having a corresponding API, because we always start feature development with the API, and then build UI on top.
Clean Design
API endpoints should be well-focused on a single area of responsibility and use consistent operations and serialization methods for any object type. With one set of rules to interact with our services, you can better automate your workflow and everything you need to do to control your media.
Take a look at the provider’s API endpoint. If every call goes against an “api.provider.com” or “services.provider.com” endpoint, with some kind of “command” or “service” parameter as a switchboard, you know that they’ve implemented a single monolithic endpoint that contains all APIs.
This makes it very hard to do federated models in which some data is local to customers while other sets are in the cloud. For example, you might want to use the API cloud for almost all services, but keep end-user transaction data locally for retention purposes. With a single, monolithic API endpoint, you can’t do this.
It also puts a brake on feature development, which slows down as teams needed to coordinate feature work and deployments in a single code base.
Finally, there’s no single scalability strategy that works for all APIs: some APIs get magnitudes more traffic than others, and the mix of read vs. write traffic is different for different APIs, but a single switchboard API has to take a lowest-common-denominator approach.
If you’re rigorous about dividing services into areas of responsibility, you avoid these pitfalls. Several years ago, we split our APIs into separate, focused services in which each API has a single job to do. Therefore, other services aren’t affected if unexpected load hits one piece of the service, and we can scale each API as appropriate.
For example, if there are an abundance of feed requests, we can simply add another feeds server instead of spinning up another instance of the entire API stack.
Here are some examples of the APIs you’d use for different functions:
- For read/write calls on media, you work against http://mps.theplatform.com.
- If you only need to do reads against media, you work against http://read.mps.theplatform.com.
- For feed configuration, you go to http://feed.data.theplatform.com.
- For delivery restrictions, you go against http://delivery.data.theplatform.com.
If you’re interested in checking out the entire Index of Web Services, we list them in our in our Technical Resource Center.
Focus on Flexibility
You can get more in-depth information when you download the white paper, including evaluation criteria for secure API calls, proprietary serialization formats vs. web standards, and notifications support. We hope that when you finish reading it, you’ll have a useful tool for starting the conversation with your potential video management system provider. And, of course, that you’ll have an appreciation of how our data model can accommodate the needs of developers working in a wide variety of technologies, organizations, and content categories.
Download the white paper, and let us know if you have any questions, or want to get more information about how we’ve designed our services.
Tweet
Comments