API as a Service: Productive Innovation with Application Integrity

Mar 4, 2014 12:00:00 AM

API as a Service: Productive Innovation with Application Integrity

At To-Increase, we keep abreast of industry conversations among technology innovators, including the buzzwords that can suddenly become prominent or obnoxious. In the last few months, the term “API as a service” has quickly gained increased visibility. Today, we try to answer the question why and when it can be a good idea to provide APIs as internet-based services.

As you probably know, application program interfaces (API) make it easier to develop software programs by providing building blocks, such as libraries and frameworks, which enable developers to create applications that can function within an operating environment. From the perspective of a software user, APIs are typically invisible. However, all programs using the same API will look similar and will be easier to learn and use than if that were not the case. APIs work by means of function calls in software programs, which link to required subroutines for execution in communicating with the operating system. The APIs in today’s complex operating systems typically include more than a thousand such calls.

In its summary of technology trends to watch 2014 to 2016, analyst firm Forrester included “APIs become digital glue” as the third item among 10. Analysts point out the similarities between hosted APIs and service-oriented architecture (SOA), and mention the Amazon advertising API and the Washington Metropolitan Transit Authority’s API as examples for enabling productive innovation. There are collaborative advantages and security considerations involved in offering APIs over the internet. If companies strike the right balance between these two aspects of internet-based APIs, they stand to benefit from more productive, less restrictive solution development that can give free rein to developer creativity.

Stronger Security and Higher Level of Control

If you provide an API as a public web service, you need to do so with a high level of security. Imagine you run an ERP system or other business-critical application in the cloud or on-premise, and you want to enable developers to build a learning application that requires access to the application’s database or processes. If you do this by using traditional APIs that are not internet-connected, you will need to give the developers access to the data model and other, deep-seated application detail. If, for reasons of data and application protection, you would rather not provide this level of access, you could instead define a highly secure API web service.

When you set up a web-based API and developers connect to it through HTTP or XML protocols, they can review process models, run queries for process models and activities, and see certain details in user screens. The developers can make use of all the exposed capabilities, and you can enable collaboration among developers or among consulting developers and your IT team. However, because you do not open your entire application for access, you are in a stronger position to keep confidential data and important capabilities uncompromised. In these scenarios, companies typically also implement complementary security measures such as encryption, the use of digitally signed keys, and the OAuth authentication protocol.

In such highly secure ways, web-based API services for ERP systems could, for example, expose the data set in To-Increase RapidValue or the functionality for creating new products in the database of To-Increase Advanced Discrete Manufacturing. Another example is Basecamp, a project management application. Close to 30 development partners access the standardized Basecamp API as an internet service to create new application features collaboratively.

Considerations and Complexities of Managing API Infrastructures

Once application owners make an API public to the developer community, changes and updates to that API can be problematic, especially if large numbers of developers are involved, as would be the case with APIs for Twitter or the Amazon Kindle. Companies need to avoid two things: breaking developers’ applications because of API changes and inadvertently promoting the obsolescence of their own API. However, if you make an API available as an internet service, the application you expose it to can still be on-premise. For example, a new capability for adding products to the Advanced Discrete Manufacturing database could provide a cloud-deployed API, which calls into the application to retrieve data.

If you also make use of data caching in the cloud, you can speed up the API’s performance and make collaboration among trusted parties easier yet. While this way you can generally maintain the integrity of your application, you may need to consider additional security measures to ward off hackers and to safeguard your application if unknown developers are involved. You could, for example, transfer the API to a location or a resource outside of your network, allowing developers to work with a copy instead of the original. They could access your API through one of the service providers that offer hosting and management of companies’ API infrastructures.

Along with encouraging the development collaborations that API as a service enables, companies need to think about how they should best provide this resource and establish the best practices in transitioning to the implied networked enterprise view. That means they need to define their API management. Frequently, organizations format their APIs in the architectural style of representational state transfer (REST) for APIs based on internet standards. REST, which is also applied to developing web services, is for many technologists a preferred alternative to the Simple Object Access Protocol (SOAP). In the view of many experts, API management is a more advanced instance of SOA, and best practices for SOA are also applicable to successful API management. The design of the API infrastructure needs to expose what users require while removing from their attention the underlying complexities. It also needs to consider the role of mobile enablement in fostering the productivity of users.

Planning for Industry-Standard APIs

At To-Increase, we are exploring what the potential advantages of API as a service are for our developers, partners, and customers. Some of our partners are looking to cloud-based APIs to streamline their solution development with greater flexibility than would be possible with SOAP-based web services. I expect that some partners will welcome the option to easily build applications that add a layer of functionality to complex data models, comparable to our Product Engineering App, which is built on the product API in Advanced Discrete Manufacturing. Web-based APIs will make it far easier to develop such apps efficiently and securely.

To-Increase might well play a leadership role in standardizing how APIs—especially in relation to operational entities and processes relevant to the industries we support—can be shared publicly to enable developer productivity without compromising the integrity of data and applications. For the manufacturing industry, one might be able to define APIs that establish working models for engineering change requests, costing, products, bills-of-materials, and other typical entities, somewhat similar to the building information model API in the architectural and construction discipline.

What is your take on API as a service? I’d be curious to know, so please get in touch.

Share this message

Related Blogs

Aug 8, 2019 11:07:10 AM
Jul 9, 2019 9:31:11 AM
Jul 1, 2019 8:09:49 AM