Request Methods in PostQode

PostQode supports several request methods that you can use to interact with the APIs and the web services. Please find below the commonly used methods:

GET

This method is used to retrieve a resource from a server and is used to fetch the data from an API or a web service.

POST

This method is used to send data to a server for processing and is used to create a new resource or update the existing ones.

PUT

This method is used to update an existing resource on a server and is similar to the POST method but is used when the resource is already existing and you want to modify its properties.

PATCH

This method is used only to partially update a resource, modifying only the specified parts.

DELETE

This method is used to delete a resource from the server and is used to remove data from an API or a web service.

HEAD

This method is similar to GET method, but it only retrieves the headers of the response and not the actual data. It is often used to check the availability or status of a resource.

OPTIONS

The OPTIONS method describes the communication options and permitted capabilities available for the target endpoint, resource, or entire server. Unlike data-retrieval methods (such as GET) or state-modifying methods (such as POST and PUT), an OPTIONS request does not retrieve or modify resources. Instead, it queries the server to inspect what HTTP features, methods, and access policies are supported.

Primary Use Cases

1. CORS Preflight Requests (Cross-Origin Resource Sharing)

The most common application of OPTIONS in modern web applications is the CORS Preflight check. When a browser executes a cross-origin request that is not considered a "simple request" (such as requests using application/json, PUT, DELETE, PATCH, or custom headers like Authorization or X-API-Key), the browser automatically dispatches an HTTP OPTIONS preflight request prior to sending the actual request.

• Client Preflight Headers Sent:

  • Origin: The domain initiating the request (e.g., https://frontend.example.com).
  • Access-Control-Request-Method: The HTTP method the client intends to use (e.g., PUT or DELETE).
  • Access-Control-Request-Headers: A comma-separated list of custom headers the client intends to send (e.g., Authorization, Content-Type).

• Expected Server Response Headers:

  • Access-Control-Allow-Origin: Specifies which origins can access the resource (e.g., https://frontend.example.com or *).
  • Access-Control-Allow-Methods: Lists permitted HTTP methods (e.g., GET, POST, PUT, DELETE, OPTIONS).
  • Access-Control-Allow-Headers: Lists approved request headers (e.g., Content-Type, Authorization, X-Requested-With).
  • Access-Control-Allow-Credentials: Indicates whether cookies and HTTP authentication can be included (true).
  • Access-Control-Max-Age: Caches the preflight response in the browser for a specified duration in seconds (e.g., 86400) to avoid redundant preflight requests.

2. Endpoint Capability Discovery (Allow Header)

REST APIs often use OPTIONS to allow clients and automated tools to discover which HTTP verbs are supported on an endpoint without triggering business logic or payload processing.

• Example Response:

  HTTP/1.1 200 OK
  Allow: GET, POST, PUT, DELETE, HEAD, OPTIONS
  Content-Length: 0

  If a client attempts to use a method not listed in the Allow header, the server should return 405 Method Not Allowed.

3. Server-Wide Capability Inquiries

Clients can query server-wide capabilities or proxy settings by sending an OPTIONS request to the server root or asterisk target (OPTIONS * HTTP/1.1). This verifies whether web servers, reverse proxies, and API gateways are operational and correctly routing HTTP traffic.

4. Security Audits and Compliance Testing

In automated security pipelines, OPTIONS requests are used to audit endpoints:

• Disabling Insecure Methods: Verifying that vulnerable or unnecessary HTTP verbs (such as TRACE and CONNECT) are disabled to prevent Cross-Site Tracing (XST) attacks.
• Strict CORS Validation: Ensuring private internal APIs do not expose permissive Access-Control-Allow-Origin: * headers alongside authenticated endpoints.

Testing OPTIONS in PostQode

When configuring an OPTIONS test case in PostQode:

1. Select Method: Choose OPTIONS from the HTTP method dropdown.
2. Configure Headers: Add simulated client preflight headers (e.g., Origin: https://app.example.com and Access-Control-Request-Method: POST).
3. Verify Response Code: Ensure the endpoint returns 200 OK or 204 No Content.
4. Assert Response Headers: Add test assertions in PostQode to validate that:
   • Access-Control-Allow-Origin matches the authorized origin.
   • Access-Control-Allow-Methods includes all required HTTP verbs.
   • Access-Control-Max-Age is set appropriately for caching.