Considerations for making Enterprise REST API Public

What are the points to consider before making an Enterprise REST API Public?

Let’s find out in this video.

Assuming that you are exposing REST APIs which most organizations are as of today, the first consideration is to follow the REST architectural standards. REST is an architectural style that defines a set of constraints to be used for creating web services. You can take a look at those architectural properties and constraints here. But without being too pedantic, you need to make sure that you use proper URIs, proper HTTP verbs and versioning methods. That will make your API more clean and easy to use for your clients.

Secondly, you need to make sure you return proper Error Codes in your responses. There are standard error codes like 404 Not Not Found, 500 Internal Server Error and 401 UnAuthorized. Many times the APIs do not return proper error codes which can make the consumption of your API very difficult for your clients. For e.g. if you return 500 because the user was not authorized to retrieve the value of a resource, the client will have no idea that the action is denied because they were UnAuthorized. They will assume that something is wrong with the server. Which can lead to confusion, customer support calls, etc.

Thirdly, you need to make sure that your API is very secure. This is a really important step. There are multiple considerations under security.

You need to make sure that you have proper authentication in place. Whether you choose to go with Basic Authentication or OAuth2.0 or API Key based authentication, you need to make sure that it’s implemented properly.

Then, second consideration under security is, you need to also make sure that you have proper authorization in place. What that means is someone is trying to take an action, once you know their identity using an authentication mechanism, you need to check whether that person can execute that action or not. You need to have proper server side checks to make sure that some unauthorized user is not able to execute action which he/ she is not supposed to execute. For e.g. you might have some sensitive data which only Admins can retrieve and not others. So you need to make sure your API returns that data to only those Admin users and not all the users.

And lastly, under security, you should look at the most common attacks that are prevalent across the web on the APIs. There is a list of OWASP top 10 attacks specifically for APIs, published by OWASP foundation which talks about such common attacks and how to mitigate them. For those you who don’t know, OWASP stands for Open web Application Security Project. It’s a non-profit organization which publishes top 10 vulnerabilities across the web for web applications and APIs. Here is the link to the OWASP top 10 for APIs. This is a great starting point towards making your APIs more secure.

Fourthly, after security, next is logs. Our API should have proper logs/ auditing in place. The logs can help us debug the issues in production, can alert us of the issues before the customer even sees them and help us track the performance of our API. We can also get amazing insights on how the customer is using our API and use that knowledge to improve our API or offerings.

Fifth, we need to have a good Documentation in place. Our clients should be able to understand what the API does and how to consume the API. You can look at some of the public APIs which already exist. For e.g. Twitter API documentation here. It’s preferable to even have sample implementation of the API consumption which can act as a starting point for our clients who are planning to use our APIs.

Sixth, you can use an API Gateway like Kong/ APIGee, etc. The gateway can help you centrally manage all your APIs. You can set up things like Rate Limiting/ Throttling and it provides additional security against attacks like Denial of Service and Injection attacks.

Hope you guys liked the video. I will be adding more such videos to the Youtube channel, so do not forget to subscribe. Until next time, happy coding 🙂