CORS can be tackled quickly with the understanding of a few HTTP headers.
Let's discuss them in a bit more detail. π§΅ππ»
We are going to cover HTTP request headers first, and then we will jump onto HTTP response headers.
π HTTP Request Headers
The client can use a few HTTP request methods with their API calls in order to make maximum use of the Cross-Origin resource sharing feature.
1οΈβ£ Origin
The Origin header indicates the origin of the request. Browsers add the Origin request header to all cross-origin requests.
2οΈβ£ Access-Control-Request-Method
Access-Control-Request-Method header is used with the preflight request to let the server know which method will be used in the main request.
For example,
Access-Control-Request-Method: POST
π HTTP Response Headers
The server sends Access-Control-* HTTP headers for cross-origin requests. ππ»
1οΈβ£ Access-Control-Allow-Origin
Access-Control-Allow-Origin tells the browser which origin value is allowed to access the resources.
For example,
Access-Control-Allow-Origin: <origin> | *
The wildcard (*) indicates that all the origins can access the resources.
2οΈβ£ Access-Control-Max-Age
The Access-Control-Max-Age header indicates the amount of time in which the result of the preflight request can be cached.
After the specified time, the browser needs to send a new preflight request.
3οΈβ£ Access-Control-Allow-Credentials
Access-Control-Allow-Credentials is used with the response of a preflight request which indicates whether the actual request can be made using credentials.
4οΈβ£ Access-Control-Allow-Methods
The Access-Control-Allow-Methods header indicates which methods are allowed to access the cross-origin resource. It is sent in response to a preflight request.
For example,
Access-Control-Allow-Methods: POST
Developing a basic understanding of CORS can save you from hours of debugging.
Read this complete thread on "Introduction to CORS"
There are different kinds of specifications available that you can use while building an API.
In this thread, we will talk about the OpenAPI spec.
𧡠ππ»
In simple terms, OpenAPI spec is a format to define structure and syntax for REST APIs.
OpenAPI spec provides a standard that allows both humans and computers to discover and understand the service's capabilities without access to source code, documentation, or traffic inspection
- Public API
- Private API
- Partner API
- Composite API
Let's discuss them in detail π§΅ππ»
1οΈβ£ Public API
Public APIs are accessible to all developers with a low or moderate level of authentication and authorization.
For example, the Windows API of Microsoft is a public API.
Stability is an essential factor of any public API. Any changes in the public API, let's say adding a new parameter, might break the applications that depend on that API.
A quick introduction to smart contracts and decentralized API ποΈ
π§΅ππ»
Before diving into Decentralized API or dAPI, we need to understand Smart Contracts. ππ»
Consider Smart contracts like typical contracts but they are programmatically generated and completely digital. Smart contracts are stored on a blockchain (a system of recording information in a way that makes it difficult or impossible to change, hack, or cheat the system).