Exploring the Basics of Rest APIs

SAP Subscription Billing uses a specific type of API called Representational State Transfer Application Programming Interfaces, also known as REST APIs.

Let’s talk about APIs first.

An API acts as a communication protocol between different software programs. It explains how they should interact with each other, providing a set of rules and instructions. Think of an API as a "middleman" that allows software programs to communicate in an efficient way. Without APIs, it would not be possible to enjoy the simple task of booking a hotel room online or updating software via the cloud.

Before REST APIs are discussed, let’s see how an API works. Watch the following video.

Now that you understand the role of APIs, let's dive into REST APIs.

REST stands for Representational State Transfer. It is an architectural style for designing networked applications. A REST API uses HTTP — a foundational technology of the internet — to request and send data. This data can work within a variety of formats, including XML and JSON.

The concept of REST is based on resources. A resource in REST API is the fundamental concept for information description; it's any information that can be named. For example, when talking about SAP Subscription Billing, a subscription can be one resource and a customer can be another. The significance of using resources instead of a large database is that each resource has a unique URL that you can link or reference.

A robust feature of REST APIs is their utilization of standard HTTP methods. These include POST which adds a new resource; GET retrieves a resource; PUT updates a resource; PATCH allows a partial update; and DELETE removes a resource.

The PUT and PATCH methods are similar as they both update a resource. For example, if you have a user profile with fields like name, e-mail, and password, a PUT request would require you to send all fields even if you only want to change the password. Using PATCH over PUT helps avoid reducing system performance with unnecessary changes when dealing with large resources or frequent updates.

An API call or operation is idempotent if it has the same result no matter how many times it's applied. An idempotent operation provides protection against accidental duplicate calls causing unintended consequences.

For example, if you repeatedly send the same DELETE request to a specific URL, the following attempts will likely fail because the data has already been deleted. The final state of the server with the deleted data stays the same after the first DELETE request. Even if the second request fails, the DELETE method is still considered idempotent because the desired end-state has been achieved and will not change with repeated requests.

For example, consider a resource that counts for each time a PATCH request is made. The PATCH request to increase the counter by 1 does not replace the counter history. Each subsequent PATCH request will increment the counter. If you apply the same PATCH request again, the outcome will differ each time and increase the counter.

Choosing an idempotent REST API method depends on your application or service.

The beauty of REST APIs lies in their simplicity. REST APIs are stateless, meaning the server does not need to know the state of the client. A request from a client already contains the information needed to fulfill a request.

Note that REST methods are not considered a standard. REST methods are a set of guiding principles and are embraced by most developers as a powerful tool to structure APIs due to their simplicity, scalability, and compatibility with the web.

APIs (Application Programming Interfaces) and REST APIs (Representational State Transfer APIs) play a crucial role in modern software development and digital interactions. APIs provide a way for different software systems to communicate and interact with each other. REST APIs have become a popular and widely adopted architecture style for designing networked systems, especially in the context of Web services and cloud-based applications.

Obtain an API key, also known as a service key, by visiting the SAP Business Accelerator Hub, accessing your API, and selecting the Show API Key button in the upper right of the page. Service keys help secure applications with a method of authentication and authorization. They play a key role in protecting application interfaces and data by ensuring that an API is accessed only by trusted, authorized users or systems.

A service key is a unique identifier that provides credential access to a particular service and can help manage and limit service usage. Service keys can be regenerated if compromised. Service keys are often long and complex strings that are difficult to reproduce, making it harder for unauthorized users to bypass security measures.

Authenticating with a service key begins by sending the key as part of a request to an API. The server compares the key with the key stored on the server. If they match, the request is authenticated, much like a typical username and password method.

In SAP Subscription Billing, the initial authentication generates a temporary identifier or access token known as a bearer token. While service keys provide secure authentication of trusted systems, bear tokens provide secure, temporary access to services following authentication.

In SAP Subscription Billing, the initial authentication generates a temporary identifier or access token known as a bearer token. While service keys provide secure authentication of trusted systems, bear tokens provide secure, temporary access to services following authentication.

Bearer tokens are not tied to a specific user; instead, they verify that a request comes from a source authenticated before.

Upon a successful service key authentication, the server generates a unique, signed bearer token and sends it back to the client. This token is then used in place of the service key to authenticate subsequent requests within that session. A bearer token helps reduce the risk of exposing a service key by eliminating the need to send the service key with every request.

Bearer tokens are generated for a limited duration and are controlled by an expiration date. The token becomes invalid upon expiration. The user must reauthenticate the service key to generate a new bearer token. A bearer token helps reduce the possibility of long-term access by an unauthorized user.

While service keys provide secure authentication of trusted systems, bear tokens provide secure, temporary access to services following authentication. Next, let’s see how to create a bearer token and find APIs.