The Basic Principles of API (Application Programming Interface)
API stands for application programming interface, a concept that applies everywhere from command-line tools to enterprise Java code to Ruby on Rails web apps. An API is a way to programmatically interact with a separate software component or resource.
Unless you write every single line of code from scratch, you’re going to be interacting with external software components, each with its own API. Even if you do write something entirely from scratch, a well-designed software application will have internal APIs to help organize code and make components more reusable. And there are numerous public APIs that allow you to tap into functionality developed elsewhere over the web.
What is an API?
An API is defined as a specification of possible interactions with a software component. An API defines functionalities that are independent of their respective implementations, which allows those implementations and definitions to vary without compromising each other. Therefore, a good API makes it easier to develop a program by providing the building blocks.
When developers create code, they don’t often start from scratch. APIs enable developers can make repetitive yet complex processes highly reusable with a little bit of code. The speed that APIs enable developers to build out apps is crucial to the current pace of application development.
Developers are now much more productive than they were before when they had to write a lot of code from scratch. With an API they don’t have to reinvent the wheel every time they write a new program. Instead, they can focus on the unique proposition of their applications while outsourcing all of the commodity functionality to APIs.
API Guidelines and Basic Principles
Some of the guidelines and basic principles described below are subjective but they are essential in today’s API development. They provide fundamental benefits and help to stay at par with industry-wide adoption of best practices:
Vocabulary
This refers to the standard naming conventions one should following while naming each API endpoint. They should be human-readable, easy to understand and follow the HTTP standards.
Versioning
By versioning, you are allowing various consumers to access your published APIs in two different variations. Though Version management adds complexity to the existing APIs, they do however help in better management of API endpoints, thereby serving various consumers through different mediums. There are two different ways to implement this:
- URL — For e.g., api.myorg.com/v1/users
- Accept Header — requesting for specific version via request/accept header
Support Multiple Media Types
At any point in time, a given object or resource can have multiple representations. This is necessary so that various consumers can request the content or resource in the manner that they would like. Having said that, it is not necessary to support all media types, only the ones that are required based on specific use cases.
Caching and Concurrency Control
Caching improves performance, thereby providing faster access to frequently accessed resources and eliminating the load on backend services. However, caching comes the challenge of managing concurrent access. Therefore, it is essential to manage the caching in a better way using HTTP standards such as:
- ETag — Entity tagging. Equivalent to versioning each entity for updates
- Last-Modified — Contains the last modified timestamp
Standard Response Codes
This responsibility lies with business owners as it affects the business needs of consumers of your APIs. The contract definition should contain all possible error codes that could occur with each API.
- Adhere to the standard HTTP response codes
- Include both business and developer messages. Developer messages should be optional and contain technical messages that guide debugging and troubleshooting techniques.
- Due to security reasons, do not reveal too much about the request (to avoid Cross-Site Request Forgery).
- The best practice is to limit the list of potential error codes, as too many error codes lead to chaos.
Security Considerations
This does not require much explanation, as security requirements are the basic needs of any application or an API. Keep in mind that your API’s are mostly public, so invest the effort required to secure them. API management platforms (explained in the later section) provides security mechanisms; however, as an API developer, you should be aware of the current trends and industry best practices adopted in addressing security requirements.
- Always use SSL
- APIs are stateless, so avoid session/cookie management — authenticate each request
- Authorize based on resource, not on URL
- HTTP status code 401 vs. 403: Some may prefer to use code 401 rather than 403 to indicate that either authentication or authorization failed
- Follow the guidelines defined by the Open Web Application Security Project (OWASP) Threat Protection
API is becoming increasingly important in web development, and its popularity and usage have increased exponentially in the past few years. Hopefully, this article has detailed the basics principles of API. If there are additional notes that I have not included, please mention them in the comments.
(SA)
