HTTP Request Node

Definition:

The 'HTTP request' node is a functional component designed for communication with external servers or APIs. It enables the exchange and manipulation of external and performance data by sending standard HTTP requests, making it suitable for scenarios such as retrieving external data, creating webhooks, generating images, and downloading files.

Quick Start/How to Use:

Node Configuration Details:In ChatInsight.AI, right-click and select "Add Node" to add the HTTP request node to the workflow.

1. Configure API Parameters for HTTP Requests

API: The API module of the HTTP node provides a convenient interface for making API calls. Users only need to enter the target API address and can choose the appropriate request method from six standard HTTP methods:

GET: Used to request the server to send a specific resource.

POST: Used to submit data to the server, typically for submitting forms or uploading files.

HEAD: Similar to a GET request, but the server does not return the body of the requested resource, only the response headers.

PATCH: Used to get the transmission path at each node in the request-response chain.

PUT: Used to upload resources to the server, typically for updating existing resources or creating new ones.

DELETE: Used to request the server to delete a specified resource.

For example, to access the AirDroid official website, the request method is typically GET: https://www.airdroid.com.

The HTTP node allows you to insert variables in the URL input box by entering/or{. The source of the variables can be outputs from upstream nodes, user inputs, or system variables.

For example, using the system variable Query (in a session-based workflow), enter/or{and then select Query to insert the user's input question as the target address for this request node.

1)'Run This Step' is a node debugging feature that allows developers to execute and validate specific nodes in the workflow independently. By clicking the "Run This Step" button in the upper right corner of the interface, only the currently selected node will be executed, enabling precise issue localization.

2)Follow This Node is also a node debugging feature. When you enable this function, the system automatically marks all the variables used in this node as watch variables and displays their summary information in real-time in the Debug Panel, helping you quickly grasp the status of the workflow.

2. Configuring HTTP Request Headers and Params

1)Headers are metadata that are attached to requests or responses. They provide additional information about the request, similar to how a stamp and address on an envelope give extra details about a letter.

Function:Contains supplementary information about the request, such as the type of request, sender information, data format, etc.

• Content-Type: Specifies the format of the data being sent (e.g., application/json, application/x-www-form-urlencoded, etc.).
• Authorization: Contains authentication information for APIs, such as tokens.
• Other custom request headers can also be used.

2)Params are key-value pairs appended to the URL that are used to pass additional query information. This is like telling the waiter at a restaurant that you want extra salt or to choose different side dishes.

Function:Used to filter or specify certain conditions for the request.

If there are multiple sets of headers/params, you can click the "+" in the upper right corner to add more, and the "delete" in the lower right corner to remove them.

3. Configuring the Body Content of the HTTP Request

The body is the actual data content transmitted in the request. It is like the main text of a letter, containing the primary information you want to convey.

Function:Contains the data that needs to be sent to the server, such as form information, file contents, etc.

Body Formats: The HTTP node provides flexible configuration for request body formats, supporting five common data formats to accommodate different interface requirements:

1. None:Means that no data is attached when sending the request. This situation commonly occurs in the following cases:

• GET requests: GET requests are typically used to retrieve data from the server rather than send data, so they usually do not require a request body. In this case, it is normal for thebodyto beNone.
• DELETE requests: Similar to GET requests, DELETE requests are generally used to delete resources and typically do not require a request body.
• No data needed: Some APIs, such as simple trigger operations or status queries, are designed not to require a request body.
• Default setting: If the request type supports a request body (like POST or PUT) but does not require any data in specific cases, the body may also be set to None.

2. form-data:A format for sending form data, typically used for file uploads.

• Usage: Mainly used in scenarios that require file uploads, as it can handle both binary and text data.
• Implementation: Uses
  multipart/form-data
  as the
  Content-Type
  , with each field having its own content description and boundary.
• No data needed: Some APIs, such as simple trigger operations or status queries, are designed not to require a request body.
• Example: Used when selecting a file to upload in an HTML form.

3. x-www-form-urlencoded:A format that encodes form data as key-value pairs, sending data in URL-encoded format.

• Usage: Suitable for sending simple form data, usually used in POST requests.
• Implementation: Data is sent in the request body in the format
  key1=value1&key2=value2
  , with special characters encoded.
• Example: This format is used by default when submitting an HTML form.

4. raw text: Refers to sending plain text data without a specific encoding format.

• Usage: Suitable for scenarios that require sending plain text data.
• Implementation: The
  Content-Type
  can be specified as
  text/plain
  to directly send unencoded text.
• Example: Sending simple text messages or logging data.

5. JSON:Used for sending structured JSON data.

• Usage: Widely used in
  RESTful APIs
  , as JSON is easy to read and parse.
• Implementation: Uses
  application/json
  as the
  Content-Type
  , with data sent in JSON format.
• Example: Sending complex objects or array data, such as {"name": "John", "age": 30}.

4. HTTP Request Timeout Setting

The Timeout Setting is a threshold parameter that controls the maximum time the request will wait for a response. You can set the timeout duration (in seconds) as needed, with a default value of 30 seconds.

Function:It helps to prevent workflows from getting stuck or delayed; it forces termination of requests that are waiting indefinitely without a response.

Common HTTP Response Status Codes

During the HTTP request process, the server returns different status codes to indicate the success, failure, or required further actions of the request. Below is a classification of common HTTP status codes and their handling methods, which can be processed accordingly:

Typical Use Cases:

The HTTP request node acts as a bridge, facilitating communication between your system and other external services or applications. Imagine your workflow needs to fetch information from external sources or send information out; this is when the HTTP request node comes into play.

• GET requests: GET requests are typically used to retrieve data from the server rather than send data, so they usually do not require a request body. In this case, it is normal for the
  body
  to be
  None.
• Calling Third-Party APIs to Collect Data: For example, retrieving the title, number of subscribers, and view count of a YouTube video via a link.
• Integrating with Internal Enterprise Systems: For instance, using the API interface of the enterprise system to periodically send collected information.

Practical Case Scenario:

Design Steps for Automated Ticket Classification Workflow in Customer Support Systems:

• 1. Start Node:
  • Collect information submitted by the customer, including account details, problem description, priority, and problem type.
• 2. HTTP Request Node (Create Ticket):
  • Request Method: POST
  • URL: API endpoint for ticket creation.
  • Body: Contains customer information, problem details, priority, and problem type.
  • Output: Retrieve the created ticket ID.
• 3. Natural Language Classifier (Problem Classification):
  • Classify user inquiries, such as technical issues and billing issues.
• 4. HTTP Request Node (Classify to Technical Support Department):
  • Request Method: POST
  • URL: API endpoint for the internal system of the technical support team.
  • Body: Contains ticket ID and problem details.
• 5. HTTP Request Node (Classify to Billing Support Department):
  • Request Method: POST
  • URL: API endpoint for the internal system of the billing support team.
  • Body: Contains ticket ID and problem details.
• 6. End Node: Conclude the workflow.

Through this workflow, a ticket can be automatically created after the customer fills in the required information and then automatically classified.

Notes

• Legal Risks: Comply with the Robots Exclusion Protocol to avoid illegal web scraping.
• Rate Limiting: Third-party APIs often have QPS (queries per second) limits to ensure fair access for all users.
• Cost Control: Some APIs charge based on the number of calls made; be mindful of pricing.

Frequently Asked Questions

Q1: How do I handle timeouts?

Adjust the Timeout Setting parameter, which has a default value of 30 seconds and can be modified as needed.

Q2: How do I find suitable APIs?

Many websites provide a variety of API interfaces, such as rapidapi.com.