What is an API and its relation to PLM?
Order dinner from your tablet. Track your activity with an app on your smartphone. Book a seat at the movies tonight with a click of a button.
APIs make all this possible, and they’re behind much of what we do online. They connect businesses, applications, data and devices so you can order pizza for dinner, listen to your favorite music while exercising or buy movie tickets in just a few clicks.
API stands for Application Programming Interface. APIs let applications talk to one another and exchange information. Technically, they’re program blocks that ease development and set up the routines, protocols, and tools needed to interact with an application.
How do APIs work?
APIs are like digital building blocks that are put together to provide a wide variety of features and functions. There are thousands of public APIs that can be used to do everything from checking a location and gathering social media information, to authenticating users.
Modern companies don’t build apps from scratch. They pick and choose among the available APIs to speed the development process, maintain a robust architecture and offer the best customer experience.
Let’s look at an example to understand how companies combine APIs to build apps.
Imagine you want to build a hotel app that helps users find available hotels in their location. The user selects where they want to stay and when, and the app provides a list of available hotels in that region. They can then use the app to select and book their favourite room.
How would you build this simple hotel app using APIs?
A basic combination of mapping, calendar, authentication and payment APIs would do the job:
The mapping API figures out what hotels are close by, while the authentication API lets loyal customers easily log in and quickly book a room. The calendar API checks out room availability and rates. And finally, the payment API allows users to reserve a room and settle their bill.
Understanding REST APIs
REST stands for REpresentational State Transfer and refers to an architectural style that uses HTTP methods and standardized web technologies. A REST API is a system where clients use a defined interface to interact with a web server via the HTTP protocol.
There are further types of APIs, such as Simple Object Access Protocol (SOAP) or Remote Procedure Call (RPC), but REST has achieved great popularity in recent years. This is mainly because REST performs well, is highly scalable, simple, and easy to modify and extend.
To get a sense of what a REST API is and how it works, imagine a café , a cashier, and a customer who wants to grab a cappuccino.
Here’s how our café works:
On one side, we have the client. Think of the client as the customer who wants to order a cappuccino for breakfast. The client could be a web application, mobile app, or smartwatch, or whatever interface wants access to the data.
On the other side, we have the cappuccino, the asset. Assets are typically stored in a database or database server.
In the middle sits our cashier, the REST API, receiving, processing, and handling requests and responses.
When the client submits a request – in this case, to get a cappuccino – the REST API receives the request, identifies the requested resource, grabs the resource and sends it all back to the client.
Anatomy of a REST API
Now that we have a sense of how a REST API works, let’s take our understanding a step further by taking a closer look at its main components.
The Client
The clients are the API consumers. They can be mobile apps, web browsers or embedded IoT devices.
Request
A REST request has two essential parts: a method, and a URI and a body. In some cases, headers may be sent to specify information about the request. If the request is intended to write new information to the system, a body is used to convey that information.
The header primarily enables a user to access a resource. Headers are also used to set the language format and compression preferences.
The method is one of the standard HTTP operators, and the URI points to the resource you want to interact with. RESTful APIs use standard HTTP methods to perform four essential operations:
- GET – view
- POST – create
- PUT – edit
- DELETE – delete
The URL is the unique identifier for the resource. It’s like any other URL on the internet, except in this case it’s used to describe the resource in an application.
Finally, the body section is only sent to create (POST) and update (PUT) transactions.
API
The API is the gateway to the server where the assets are. It provides access to those assets the company wants to share. A well-designed API defines what it can provide and how to use it in a “sort of contract”. Available methods, query parameters, response format, request limitations, language support etc. should be part of that contract.
APIs also act as a bodyguard for the exposed assets. There are three main security measures that most APIs use: identification, authentication, and authorization. API keys are unique codes that are generally used to authenticate users and manage access.
Assets
Assets can be data points, programs or services that a company owns and wants to expose. They’re the bread and butter of any API. The ultimate goal of any API is to share assets. Assets can be anything a company wants to share—whether it’s data, services or insights.
Response
Every response comes back from the server with a status code indicating the success or failure of the action requested.
Responses in REST APIs typically use JavaScript Object Notation (JSON). The JSON format is compact and easy to transmit on slow networks.
Let’s return to our café to see these API components in action. The customer orders a cappuccino and the cashier creates a new item: an order. The client wants to add extra sugar to her order, so the cashier updates the order. When the client asks the cashier to tell her what she’s ordered, the cashier reads the order. Suddenly the customer realises that she’s left her wallet at home, so she cancels the order. The cashier then deletes that item.
APIs in action
To better understand how APIs work, let’s look at an API in action. We’ll use an API management tool called Apigee to visualize the examples’ requests and responses. Apigee is a platform that provides API design, management and support tools.
Let’s start with a simple call to the Google API. In this example, we want to dig out Madrid’s GPS coordinates.
Method: GET—This is the read method in HTTP.
URL: http://maps.googleapis.com/maps/api/geocode/json?address=Madrid —The URL points to the resource location. For GET methods, you can try typing the URL into the browser.
Body: none— A GET request doesn’t need a body, because we’re just reading a resource from the server.
By sending the previous request to the Google Maps server, we’ll get Madrid’s latitude and longitude:
Let’s now go ahead and use the Twitter API to send a tweet.
First, we need to authenticate ourselves with our Twitter account, so that Twitter knows that the request comes from us. Then we select the POST status update method from the Twitter API and set the parameters.
I’m sending out “Test tweet from Share PLM” from Madrid, using the latitude and longitude as input parameters we gathered from Google Maps’ API. We go ahead and click send, and check that the tweet has been posted correctly.
In the response, we also get metadata such as id or status about the tweet we just created.
We could then go ahead and delete the tweet we just created using the “destroy” method from Twitter’s API.
As you can see, there are lots of APIs you can tap into and play with. The idea is to mash several APIs together to create apps and consume data easily.
Will PLM jump into the API fray?
APIs have become the operating system of digital businesses, connecting previously siloed systems and applications. Designed to be flexible, nimble and scalable, APIs provide an efficient way to build the digital services that today’s connected consumers expect.
The API economy has the potential to transform the PLM arena as well.
Businesses can expose their services and product information to their customers. But also, internally, they can connect applications and share core system data through APIs. For instance, you might want to build internal applications that access core systems for reporting, business intelligence or visualization.
PLM software providers can enable businesses and partners to plug directly into their systems, easing integrations and exposing information and functionality. PLM APIs can potentially be open to internal developers, to partners or external developers. Products like Propel PLM, OnShape, Fusion 360, OpenBOM or Aras are moving forward in this direction.
There might even be a big piece of cake for startups in the API economy. How about a completely new way of implementing PLM with on-demand, flexible APIs?
