Q&A: Why APIs are not SOA++
Our recent webcast entitled “Why APIs are not SOA++” was a popular one. We think the topic of how to build separate API and service tiers to power interactions across all channels is quite compelling. So did many of you, judging from the lively discussion the webcast generated. We didn’t even come close to answering all of your questions and comments, so here are most of the ones we didn't get to during the webcast. Thanks to all of you who participated!
How do you balance the benefits of more interactive approaches such as WebSocket and RPC (remote procedure call) versus the ease of consumption offered by REST-based APIs?
Ideally, WebSocket and RPC are served by your API tier. WebSocket in particular is often used to power user interactions.
What is ESB?
ESB stands for Enterprise Service Bus (https://en.wikipedia.org/wiki/Enterprise_service_bus). It is one of the main software architectures used for building a service-oriented architecture.
Isn’t ESB required only for web services, not for APIs?
ESB can connect to any "end point;" it does not have to be a web service. ESB is an architecture, first and foremost. There are a variety of ESB products and they support different types of end points and connectors. Traditional web services are usually supported, as are message buses (often via JMS), and a few do support REST APIs.
What is meant by "orchestration" in this context?
Orchestration here means the configuration and connection of one thing to another, like one API talking to another API or app, or ESB. In an ESB context, orchestration is connecting or applying one or two enterprise patterns (mediators) from an in-sequence flow to an out-sequence flow.
Orchestration also includes facilitating requests to multiple backend services, ESB, and app servers for any given client request. It can potentially also include authorization, unless security includes AuthN and AuthZ.
Orchestration in this context is also about mapping requests into a set of processes, code, or service endpoints. In the webinar, we discussed the scenario where orchestration is used to create application-specific APIs designed to support a certain set of interactions or deliver an overall experience by mapping those APIs into underlying, general-purpose APIs that provide access to general-purpose services. This is often done through configuration, but increasingly is also done via coding, and is a common use for node.js scripts.
In previous webinars, you usually talked about SOA as being SOAP, or SOA being less focused on the fact that it is an architecture than a technology. Since SOA is the principle of componentization into the concept of services, and services do expose some sort of API, is API simply a way of saying “loose contract?”
APIs are a way of powering applications. These APIs may be loosely-coupled (ideally) but also might be tightly-coupled if necessary.
From a governance perspective, is it the right approach to have customized APIs?
It should be a goal of API governance to drive generalization and reuse, but the primary measure of good API governance is the agility of the development of API-powered applications. API governance should ensure that customized APIs follow the same patterns for access control, rate-limiting, versioning, and documentation that general-purpose APIs do. It should also ensure that customized APIs are built as facades against general-purpose APIs wherever possible.
However, it’s not a failure of API governance, nor is it intrinsically a wrong approach, to have customized APIs within the enterprise’s API portfolio. It is a failure if these APIs are hidden inside the app server tier, are undocumented, or have inconsistent security and access control mechanisms. This is one of the key differences between an API tier and a SOA tier. In the SOA tier, custom or application-specific endpoints are definitely an anti-pattern.
Please cover the maturity of REST/JSON model with regards to schemas and extensibility.
Canonical data models (and services) can be very time consuming with not much benefits, depending on the project. Just be aware.
This is true. Building the application-specific API first and then generalizing canonical data models and services is often the more programmatic approach, and definitely the preferred methodology for agile and lean developers. However, there are many cases where the need for general-purpose services is readily apparent.
If interaction design is key to API design, and then analytics, how do you evolve current heavyweight CMS-based channels, such as Adobe CQ5, which are more typical in the enterprise context?
This is a good question, and I’ve spent enough time in enterprise portals, content management systems, and blogging platforms to have seen this firsthand. Monolithic interaction channels such as app servers and content management systems have their place and can accelerate your productivity significantly when the interaction channels are well-defined and not in flux. In many ways, APIs are more disruptive of these architectures than they are of your integration architectures. Ultimately, the adaptable universal interaction channel stack will need to be API-based.
We have built an entire API platform for education with canonical APIs and resources in the APIs. We have over 100 internal and external clients using them to much success.
Sounds like a great API success story.
How do you propose to manage the API sprawl that could occur?
First thing is to make sure you don’t already have an API sprawl that you are unaware of. If you are putting app servers in front of your API tier, and those app servers are exposing APIs to communicate with their browser-based or mobile client logic, then you already have an API sprawl. Those APIs need to be managed and secured in a consistent way.
Do you govern contracts as carefully for APIs as SOA services? If it’s a channel strategy, there may be dependencies that need to be carefully managed.
You should probably be using the API facade/chaining pattern in a situation where you are concerned about these dependencies.
For teams developing new enterprise APIs for internal consumption, what are the design considerations to facilitate future integration into the API tier? Should teams aim for some uniformity across the SOA and API tiers?
Ideally you’re creating a general-purpose API that maps to the core service as a starting point and then supplement it with app-specific APIs as needed. For more information, check out this webcast on API design.
What's the recommended way to build an "API server" with API transformations (API-to-API), data transformations, and business logic for the data? Usually ESB does it, but it would be great to have one server that does ESB and API management.
This functionality is present in some API management platforms. It can also be built within app servers and frameworks such as node.js, as long as the API governance model ensures that all such APIs are built consistently and with uniform security policies.
Are we going to see intelligence being built into the API layer that is device- and application-aware and therefore can adapt but still utilise a common set of resource locations?
This is definitely something you should expect to see.
API tier analytics is interesting, but how do you capture the unique contextual elements of each channel, such as mobile, location, or page navigation through a site?
You should use some form of event API to capture that information. Apigee offers such capabilities in its platform.
What replaces WSDL (web services description language) in the world of APIs? Is such a formal description unnecessary? Is everything replaced by patterns and docs?
REST often allows for a pattern-based approach. However, formally defined SOAP APIs are allowed in the world of APIs if necessary. Many developers find they don’t benefit from the added overhead of those APIs.
What technical and organizational challenges does an API-first architecture bring about?
In an organization that is incorporating APIs and non-web interaction channels such as mobile, many of these challenges are already underway and an API-first strategy sheds light on them and provides a conceptual framework for resolving them.
I have a set of APIs exposed for a business (e-commerce) application that often streams a reasonably large amount of data over the internal network. Now I'd like to build a mobile app, and prefer not to stream a load of data over the wire.
This is a great example of the need for mobile-optimized and composite APIs. You will want to build an API-facade that provides the minimal data necessary to support your app.
Should I consider rebuilding a new set of lightweight APIs and focus their consumption for new mobile apps, or should I instead create a facade (again, lightweight) and share it across the web as well as mobile apps, thereby reducing maintenance footprints?
Ideally, you should do both.
Ideally, where should the authentication and authorization of the requests happen?
Authentication and authorization should occur in the API tier and should be consistent across application-specific APIs, as well as general purpose APIs.
With ubiquitous mobile computing introducing new requirements, it becomes clear that to do apps well, you need more than SOA.
Download the eBook: Extending Your SOA in the API Economy