An API (Application Programming Interface) is a tool that enables different software components to communicate and exchange information. It provides a standardized and uniform approach based on interoperability, by which developers can perform operations such as data transmission and function calls easily.
When external parties call an API, they do not need to delve into the source code of the system or understand its processing details. By simply passing information in a specific format to the API, they can obtain the required data or execute particular operations.
Take the API https://holiday-api-en.vercel.app/api/holiday/info/2024-01-25 that determines whether a given date is a public holiday as an example. The following table shows the output.
Values of type are explained as follows:
Workday
By accessing this link, you know that 2024-01-25 is a workday. You can replace 2024-01-25 with any other date in the same format to query whether it is a holiday.
APIs can be categorized into several types, including HTTP-based APIs, RPC APIs, web services, database access APIs, and more.
Typically, APIs refer to those transmitting data over the HTTP protocol. Common HTTP request methods include GET, POST, PUT, and DELETE.
GET is used to request a resource from a specified URL, such as an HTML document, image, or video. GET requests are generally intended to retrieve data without modifying any data on the server.
In GET requests, parameters are usually appended to the URL after a question mark (?), with multiple parameters separated by ampersands (&).
Example:
GET requests transmit parameters in plaintext, making them unsuitable for sensitive information. There is also a size limit for the data to be transmitted, around 4 KB (which may vary across browsers).
POST is used to submit data (such as submitting forms or uploading files) to a specified resource for processing. POST requests may result in resource creation and/or existing resource modification.
Unlike GET requests, in POST requests, data is placed in the request body rather than in the URL, making them relatively more secure as data is not exposed.
POST requests have no data length limit.
PUT is used to replace a resource. If the resource does not exist, it will be created.
Unlike GET requests, which only retrieve data, PUT requests replace the existing data at the target location.
Common use cases include updating user information, uploading files, and modifying the configuration.
PUT and POST are similar in that both can submit data to the server.
PUT requests typically specify the exact location where the resource should be stored. (That is, the client determines the URL.)
For POST requests, the server decides where to place the submitted data, which may result in resource creation or existing resource updates.
DELETE is used to request the removal of a specified resource from the server.
Parameters can be passed either in the URL or in the request body.
Use DELETE with caution, as it may delete important resources on the server.
To successfully call an API, you need to understand its key components, including the endpoint URL, request method, required permission, and request parameters.
Task the List group members API as an example.
Variables used to pass information
This section specifies the names and rules for fields to be included in the request, such as field names, data types, and whether they are mandatory. These parameters can reside in:
URL
Request headers
Request body
Parameter Description for GET Requests
GET requests can pass parameters, typically in the URL.
GET requests can contain header parameters.
In the documents of GET-based APIs, Path Params and Query Params refer to parameters passed via the URL.
Parameter Description for POST Requests
A POST request typically consists of the URL, Headers, and Body. In the documents of POST-based APIs, Path Params and Query Params refer to parameters passed via the URL, similar to those in GET requests. The main data of POST requests is usually placed in Body.
This section demonstrates how to make GET and POST requests in Postman.
GET Request
Example API: List User Group
In Postman, you can either append parameters to the URL or enter key-value pairs on the Params tab page, which will be automatically appended to form the query string.
Click Send, and the response is shown in the following figure.
A GET-based API has been successfully called.
POST Request
A POST request typically consists of the URL, Headers, and Body. In the documents of POST-based APIs, Path Params and Query Params refer to parameters passed via the URL, similar to those in GET requests, and Parameter usually refers to parameters in Body.
Example API: Get user_access_token
https://open.larksuite.com/open-apis/authen/v2/oauth/token
Set the Content-Type header to application/json when calling this API. (In Postman, when POST is selected as the request method, this header is added by default.)
Parameters are passed via Body.
See the "Request Body" section of the API document.
Call this API in Postman, as shown in the following figure.
A POST-based API has been successfully called.
1. Call an API.
In the Data Synchronization node, Parameter Assignment node, and API Input operator, you can call third-party APIs to obtain data.
2. Create an API.
Data Service enables you to encapsulate and publish processed and integrated data as standardized APIs for external systems to call, achieving data value output and data sharing.
3. Output data to an API.
You can use the API Output operator to output processed data to an API.
To successfully call an API, you need to read its document to understand the endpoint URL, request method, required permission, and request parameters before calling.
You need to finish the following settings to call an API in FineDataLink.
Request Method and URL
1. Request method: HTTP request methods include GET, POST, PUT, DELETE, and more.
2. URL: Enter the URL of the API endpoint.
Params
Add query parameters on the Params tab page. The added key-value pairs will be appended to the URL.
As GET requests have no request body, query parameters are the primary means of passing data for them. Query parameters are also applicable to other request methods such as POST and PUT.
Authorization
It verifies whether you have permission to access the required data from the server.
It allows you to configure and add authentication information before sending an API request, enabling access to protected API resources. API providers typically enforce authentication using credentials such as API secret keys, access tokens, and usernames and passwords to ensure that only authenticated users can access protected API resources.
For example, to enter a residential area, you need an access card to verify your identity. Authentication works similarly to that access control system.
1. No Auth (No Authentication)
This method requires no credentials or parameters, suitable for APIs that do not require authentication.
2. Bearer Token
Bearer Token authenticates requests using an access key (for example, JSON Web Token (JWT)). The token is a text string included in the request header.
To use Bearer Token:
Select Bearer Token from the dropdown list.
In the Token field, enter your API key value or store it in a variable and reference the variable by name for enhanced security.
3. Basic Auth
Basic Authentication is a relatively simple authorization method that requires a valid username and password to access data resources.
To use Basic Auth:
Select Basic Auth from the dropdown list.
Enter the username and password.
4. Other authentication methods include Inherit auth from parent, Digest Auth, Hawk Authentication, and others. They are not detailed in this document. You can search for more information as needed.
Headers
Headers are a set of key-value pairs defined in the HTTP protocol to describe the client's environment information, request preferences, or authentication details. As part of an HTTP request, headers contain information such as the operating system, browser type, request method, and language. The server processes requests and generates appropriate responses based on this information.
For example, the document Request syntax and signature method V3 specifies header parameters that must be included to call relevant APIs.
1. Accept
This header specifies the media types that the client is willing to receive from the server, such as text/plain (plain text), text/html (HTML document), image/png (PNG image), and application/json (JSON data).
2. Accept-Charset
This header specifies the character sets the client can recognize, for example, Accept-Charset: utf-8.
3. Authorization
This header is used to verify the legitimacy of the request with the authentication credentials.
4. Content-Type
In HTTP protocol message headers, this header indicates the media type of the request or response body. It informs the server how to handle the request data and informs the client (typically a browser) how to parse the response data, for example, displaying an image or parsing and rendering HTML.
It is typically used in POST and PUT requests.
JSON is a lightweight data format that organizes data as key-value pairs.
Parameters must be valid JSON data to use application/json and are placed in the request body without any processing. The server/client parses the data as JSON data.
Unlike application/x-www-form-urlencoded, this is a multipart media type.
A boundary string is first generated to separate different fields. In the request body, each parameter begins with --boundary, followed by additional information and the parameter name, then a blank line, and finally the parameter value.
Multiple parameters result in multiple boundary blocks. If a file is being transmitted, the filename and file type information must be included. The body ends with --boundary--.
multipart/form-data supports file uploads and is typically used for form uploads.
It indicates that the transmitted data is plain text without any specific format or structure.
It is typically used for transmitting format-independent text, text messages, and other data.
5. All types are not detailed in this document. You can search for more information as needed.
In FineDataLink:
1. Content-Type description:
The system supports various media types such as application/x-www-form-urlencoded, application/json, application/xml, multipart/form-data, text/xml, and text/plain.
You can enter a value not in the drop-down list of Parameter Value on the Headers tab page.
2. You can customize header parameters.
Body
It is used to transmit data from the client to the server, commonly required for HTTP methods such as POST and PUT that carry data in the request body.
Different APIs may require different request body formats, such as JSON, XML, and form-data.
The linkage between settings in Body and the Content-Type value in FineDataLink is described in the following table.
TLS/SSL Self-Signed Certificate Authentication
APIs for which HTTPS is enabled support self-signed certificates.
After a self-signed certificate is configured, HTTPS requests are handled according to the SSL/TLS protocol.
滑鼠選中內容，快速回饋問題
滑鼠選中存在疑惑的內容，即可快速回饋問題，我們將會跟進處理。
不再提示
10s後關閉
Submitted successfully
Network busy