Wowza Streaming Cloud: API vs. SDKApril 15, 2019
Wowza recently released two new SDKs for the Wowza Streaming Cloud™ service: one for Ruby and one for Java. The goal of this is twofold.
- To provide a comprehensive range of programming options for our developer community, allowing customers to work in their preferred environments.
- To gather feedback and ensure we’re delivering the right functionality.
You might be wondering, why so many options? The answer is simple. We want you to have enough choices to meet your development needs and goals.
Let’s use a silly analogy. You need to go to the grocery store which is a kilometer away. Should you walk there or drive? Both options are equally good, depending on what your goals are. If your goals are to load up on as many groceries as possible, you’re better off driving to easily transport everything you purchase home. Conversely, if your goal is to get some exercise in and you only need a few things, walking to the store would be a great option.
The merits of using a REST API vs. a client library SDK can be described similarly. An API is an interface that allows software programs to interact with each other, whereas an SDK is a set of tools that can be used to develop software applications targeting a specific platform. An API can be seen as a simple SDK without all the debugging support. APIs are more or less interfaces to specific services, while SDKs are a set of tools, components, and classes for a specific purpose.
Wowza Streaming Cloud REST API
The Wowza Streaming Cloud REST API is both RESTful and a web service. By virtue of being a web service, you get some loose coupling. The client doesn’t need to be aware of internal implementation details and there is a real opportunity for platform and language independence.
Being RESTful offers additional benefits aimed at further decoupling, so as to improve scalability. REST forbids conversational state, allowing us to scale very wide by adding additional server nodes behind a load balancer. The universal identifiers embodied by URLs enable any tool that works with HTTP to play ball with our service. A client doesn’t need to learn any custom naming convention. This also means that the client doesn’t need to understand anything more than the data format.
Wowza Streaming Cloud Ruby and Java SDKs
Our native libraries, by comparison, are more tightly coupled into your application framework. The Ruby and Java SDKs allow stateful or domain-specific communications that offer some performance improvement, but potentially at the cost of complexity. To use a native SDK, you must be intimately familiar with naming conventions and other specific implementations, and your application will depend on local libraries being installed.
Using native code has the obvious advantage of giving you full leverage over the implementation of your product. You can be sure everything works because you’ve looked at the specifications and written code to conform with them as efficiently as possible. However, the drawback is tighter coupling. Your feature might be platform-dependent and require the user to have specific technologies or libraries/binaries available.
With a RESTful web service, you don’t have to deal with the internal workings of that particular feature. Often, you don’t even need to implement it at all if you’re using someone else’s service. It’s simple to use: send a particular request to an endpoint, get data back. The only thing you’re responsible for is knowing where to send what type of request, what information to supply, and what kind of information you will be receiving. The downside here is that this tends to involve asynchronous programming, which can become a headache depending on the situation.
Choices for Your Development Needs
Our REST API, Ruby SDK, and Java SDK are all tools for interfacing with the Wowza Streaming Cloud service. Some users may prefer using loosely coupled RESTful calls where they only need to pass data back and forth, whereas others may prefer to use our client SDKs with specific naming conventions, object methods, and other language features. Both directions are equally valid, and a hybrid approach may even be the right choice. It all just depends on what your goals are.