This blog post is to help the developers who are new to SAP APIM.Here, We are going to divide SAP APIM into 4 parts to understand it better. It is a API Development platform where you will work on-
- Swagger
- API Portal
- Developer Portal
- API Client SDK
The first 3 topics above are very crucial for development. And the last one is if you are interested in SAP APIM DevOps Area.
Swagger:
What is a Swagger?
Swagger (also known as API Specification) is a industry standard way of documenting an API. This can be provided to the clients or the Front-end developers who can further proceed and implement these API's in their code.
How to develop a Swagger?
It can be written in either JSON or YAML. If you develop your Swagger in JSON, you can always convert it into YAML and vice-versa.
Industry Standard for designing a swagger is
Swagger 2.0. But
Swagger 3.0 has more features and is getting preference now a days.
If you are planning to learn Swagger 2.0, you can go throw this link.
Click Here.
If you are planning to learn Swagger 3.0, you can go throw this link.
Click Here.
How to utilize a Swagger After development?
Once a Swagger is designed, it can be utilized to validate input payload without any major changes. I'll try to create a sepeate blog post for it.
Swagger is preferred to be shared with the client in SwaggerHub because of it's multiple features. My preference to go for SwaggerHub is the versioning of Swagger. This way, Swagger can be always be versioned and changes can be easily identified between the versions.
One more thing, there is no version control neither in SAP API Portal nor in SAP Developer Portal at the time of writing this blog, So, you can always have the swagger in SAP API Portal but if you want to handle version control, then I would suggest to maintain in both paces: API Portal and in SwaggerHub.
API Portal( where we develop API's)
SAP API Portal is a place where a API development, Monetizing API and Analyzing the logs is done. Let's go one by one.
API Development
In SAP API Portal is an API Gateway.
Once a API request is done by user, you can add multiple Security layers, Handle Traffic to backend server, Do some basic mediations like custom Error messages, and many more before sending data to backend server.
And when you recieve response from backend server, again you can do many types of Validations, and changes before sending it to the user.
How is the API development done?
There are Policies which are the lowest-level building blocks to do anything on API request and API response. Policies like: Raise Fault, VerifyJWT, XML Threat Protection, and many more. If the inbuilt policies are not sufficient, one can always use Extension policies like: JavaScript, and Python Script for writing custom policies for your requirement.
Once a Policy is developed, you can add it in many places... Before a request is sent to the server... or after a response is sent from the server... etc... You can also have logics based on your own conditions... Thus the whole implementing Policies is done on 6 levels.
- ProxyEndPoint Preflow
- ProxyEndPoint Conditional Flow
- ProxyEndPoint Postflow
- TargetEndPoint Preflow
- TargetEndPoint Conditional Flow
- TargetEndPoint Postflow
Let's say all the policies are implemented and you would like to add some overall API Properties, like the API is always triggered with gzip compression or change the Connection idle timeout, Target connection timeout or configure the type of http request(HTTP 1.0 or HTTP 1.1). All these and many more properties come under
Let's say you have multiple backend server's which you want to connect to single API request depending on the request URL, request params, body or request METHOD..., you can use the below mentioned option to configure such a case.
Developer Portal( where we publish API's)
Once an API is developed in API Portal, you need to show it to the client. This is where Developer Portal comes into picture.
So, let's go here from the client's perspective:
- API's are the building block of a Product.
- And Products are the building block of a Application.
Let's take an example. You have developed 5 API's related to customers. So, you create a product called Customers. Now, there are multiple clients who wants to use your Product, So you create a Application for each of your client.
This concept of API's, Products and Applications has been implemented in Developer Portal and every application can be viewed only by the client who created it and the API Administrators. And Client also has permission to Analyse the number of calls done, number of 400 errors, and some basic analysis of the API's that are used in their application.
There is a special feature called custom attributes for every product which can help if your API's end users are actual customers.i.e., if you have lot's of people who will use your products, then you can make API Gateway as a OAuth2 Authenticator and handle scopes in Custom Attributes Tab. That way.., based on the scope sent by the client application, you can always customize your API's: depending on which users have access to the specified API's.
Also, when a client registers into Developer Portal, you can always restrict API's on which API's to be viewed to that specific users... So, by default API's are classified as public, private and classified API's...
- Public API's can be viewed by every client that is registered.
- Private API's can be viewed by a group of clients that are registered.
- Classified API's can be viewed when a specified client is registered and requests the developers for the access.
This type of classification can also be handled by Developer Portal.
Client SDK
SAP API Management also provides something called as Client SDK. This consists of APIM CLI and APIM API which can be used to develop your API locally and deploy API through APIM CLI. This way, it can reduce the time of development. And also handle the versioning in some VCS tools like github.
So, When a API is developed locally, we can upload code to github and this can in-turn deploy the code in SAP APIM using CLI. This can help in full-on faster development of API's. This can lead to a new area where once code is developed, we can deploy it in test and in production with a single click. That's my hope atleast.
Conclusion
Hope everyone has understood the basics of SAP APIM and how SAP APIM works. This blog post tells you almost everything SAP APIM does and if you think this will help in your development, then start going through the basics of SAP APIM and do hands-on on developing APIs. SAP APIM has a lot of features which will help in API Development. Let's see how far you explore.
Sai Sreenivas Addepalli.