API stands for Application Programming Interface. It is a set of rules and protocols that allows different software applications to communicate and interact with each other. An API defines the methods and data formats that applications can use to request and exchange information.
APIs can be used to enable different software systems, services, or platforms to interact with each other seamlessly. They provide a standardized way for developers to access certain features or data of a software application without having to understand the underlying implementation details. By using APIs, developers can save time and effort by leveraging existing functionality rather than building everything from scratch.
APIs can be found in various contexts, such as web development, operating systems, libraries, and frameworks. They are commonly used to retrieve data from remote servers, send data to external systems, integrate third-party services, or automate tasks.
API Requests (or requests) are a way to interact with an API (Application Programming Interface) through HTTP requests. An API is a set of rules and protocols that allow different software systems to communicate and share information with each other.
The base URL in an API is the fixed part of the URL that is common to all requests made to the API. It defines the initial domain and path for accessing the API endpoints. From the base URL, you can add specific paths to each API endpoint or resource.
In our system, the base url is: http://neopay-master.test
HTTP verbs, also known as HTTP methods, are the main methods or actions that can be performed on a web server. They indicate the type of operation being requested on a specific resource. Below are some of the most common HTTP verbs and their meanings:
| Verb | Description |
|---|---|
GET |
The GET verb is used to request data from a specific resource. It is used to retrieve information from the server. Example: GET /api/customers - Retrieves the list of API customers. |
POST |
The POST verb is used to send data to the server to create a new resource. It is often used to submit forms or send JSON data to the API. Example: POST /api/customers - Creates a new customer with the provided data. |
PUT |
The PUT verb is used to fully update an existing resource on the server. It sends all resource data to replace the existing ones. Example: PUT /api/customers/{id} - Updates the customer data with the given data. |
PATCH |
The PATCH verb is used to partially update an existing resource on the server. It sends only the data that needs to be modified, without affecting the rest of the resource's data. Example: PATCH /api/customers/{id} - Partially updates the customer data with the given data. |
DELETE |
The DELETE verb is used to delete a server resource. Example: DELETE /api/customers/{id} - Remove customer. |
| --- |
Parameters in APIs are additional information provided in a request to adjust or filter the results returned by the API. They are used to customize the way the API responds to requests. Parameters are specified in the HTTP request URL and can be classified into two main types: query parameters and path parameters.
GET /api/links?status=activeIn this example, we have only one query parameter:
status=active: Specifies that we only want links with status = activeFor POST, PUT, and DELETE requests, parameters not included in the URL should be encoded as JSON with a Content-Type header of application/json:
{
"id": "98fa8d80-bb04-4a39-a5c0-b69ca5708664",
"name": "John Doe",
"email": "johndoe@gmail.com",
"phone": "+33 7 65 31 39 61",
"city": "Paris",
"state": "Île de France",
"zip_code": "70123",
"street": "Avenue Victor Hugo.",
"house_number": "33"
}HTTP status codes are three-digit numbers that are returned by a server to indicate the status of a client's request made over the Hypertext Transfer Protocol (HTTP). These status codes provide information about the outcome of the request and allow the client and server to communicate effectively. Here are some commonly used HTTP status codes along with their explanations:
| Status | Description |
|---|---|
200 OK |
This status code indicates that the client's request has been successful. It is used when the server successfully responds to a GET, POST, PUT, or DELETE request. For example, if a client requests a web page and receives the content without any issues, the server will respond with a 200 OK status code. |
201 Created |
This status code is used to indicate that a new resource has been successfully created as a result of the client's request. It is often sent as a response to a POST request. For instance, if a client submits a form to create a new user account, and the server successfully creates the account, it will respond with a 201 Created status. |
400 Bad Request |
This status code indicates that the server cannot process the client's request due to invalid syntax or parameters. It is commonly used when the client sends a request that the server cannot understand. For example, if a client submits a form with missing or incorrect data, the server might respond with a 400 Bad Request status code. |
404 Not Found |
This status code indicates that the server cannot find the requested resource. It is commonly used when the client requests a URL that does not exist or is not available. For instance, if a client tries to access a web page that has been removed or entered an incorrect URL, the server will respond with a 404 Not Found status code. |
401 Unauthorized |
The status code 401 Unauthorized indicates that the request made by the client lacks valid authentication credentials. It means that the client needs to provide valid credentials to access the requested resource, but it has failed to do so or the provided credentials are invalid. |
500 Internal Server Error |
This status code indicates that an unexpected error occurred on the server while processing the client's request. It is a generic error message used when the server encounters an internal issue that prevents it from fulfilling the request. For example, if there is a problem with the server's configuration or a programming error, it might respond with a 500 Internal Server Error status code. |
These are just a few examples of HTTP status codes, and there are many more with specific meanings. Status codes in the 1xx range represent informational messages, codes in the 2xx range indicate success, codes in the 3xx range indicate redirection, codes in the 4xx range indicate client errors, and codes in the 5xx range indicate server errors.
API rate limits refer to restrictions set by API providers on the number of requests that can be made within a specific time frame. These limits are imposed to prevent abuse, ensure fair usage, and maintain the overall performance and availability of the API. By implementing rate limits, API providers can control the rate at which clients can access their services.
API rate limits are typically defined in terms of two parameters:
Rate Limit Window: This is the time frame during which the rate limit applies. For example, a rate limit window of 1 hour means that the limit is enforced over a period of 60 minutes.
Request Limit: This is the maximum number of requests allowed within the rate limit window. It represents the threshold beyond which additional requests will be denied or delayed. For instance, if the request limit is set to 1000, only the first 1000 requests will be processed within the specified time frame.
Here are a few examples to illustrate API rate limits:
Twitter API: The Twitter API imposes rate limits to control access to its resources. For certain endpoints, the rate limit might be set at 15 requests per 15-minute window. This means that a client can make up to 15 requests within a 15-minute period. If the client exceeds this limit, further requests will be blocked until the window resets.
Google Maps API: The Google Maps API applies rate limits depending on the API key used and the type of service being accessed. For example, the Geocoding API has a default limit of 50 requests per second. If a client exceeds this rate, they may receive error responses or experience delays until the rate limit resets.
All dates are returned in format UTC: YYYY-DD-MM HH:MM:SS
API pagination is a technique used to retrieve large sets of data from an API in smaller, manageable chunks called pages. When an API response contains a large number of items or records, pagination allows the client to retrieve the data incrementally rather than all at once.
The purpose of API pagination is to improve performance, reduce network bandwidth usage, and enhance the overall user experience by breaking down large result sets into more manageable portions.
Pagination typically involves the following components:
Page Size/Limit: This represents the maximum number of items or records returned in a single API response. It determines the size of each page. For example, a page size of 50 means that each response will contain a maximum of 50 items.
Page Number/Offset: This indicates the position of the page within the overall result set. The first page is usually denoted as page number 1, the second page as page number 2, and so on. Alternatively, some APIs use an offset value that represents the number of items to skip before starting a new page.
Total Count: This specifies the total number of items or records available in the entire result set. It helps the client understand the overall size of the data and determine how many pages are needed to retrieve all the items.
Example
{
"current_page": 1,
"data": [
{
"id": 1,
"title": "Post 1",
"content": "Lorem ipsum dolor sit amet."
},
{
"id": 2,
"title": "Post 2",
"content": "Sed ut perspiciatis unde omnis iste natus error."
}
// ... other posts on the current page
],
"first_page_url": "http://example.com/posts?page=1",
"from": 1,
"last_page": 5,
"last_page_url": "http://example.com/posts?page=5"
// ... other pagination information
}An API version refers to a specific iteration or release of an application programming interface (API). An API is a set of rules and protocols that allows different software applications to communicate and interact with each other. APIs are commonly used in software development to enable the exchange of data and functionality between different systems.
As software evolves over time, APIs may undergo changes to add new features, fix bugs, or improve performance. Each significant update or modification to an API is typically assigned a version number to distinguish it from previous versions. API versioning helps ensure compatibility and provides developers with a way to manage changes in a controlled manner.
Version numbers for APIs usually follow a specific format, such as "major.minor.patch." The major version number often indicates significant changes that may introduce breaking changes, while the minor version number represents added features or enhancements that are backward-compatible. The patch version number typically indicates bug fixes or minor updates that do not introduce new features.
For example, an API versioned as "v1.2.3" implies it is the first major release (v1), with two minor updates (2) and three patches (3) applied. Developers can reference the specific version of an API to ensure compatibility and maintain consistency when integrating it into their applications.