Technologies and Software Engineering

Understanding HTTP, REST, and the OPTIONS Method

REST, an architectural style for web services; and the OPTIONS method for querying server capabilities.

Overview

HTTP (Hypertext Transfer Protocol) is the foundational protocol for data communication on the web, with REST defining a set of architectural principles for designing web services that leverage HTTP methods to manage resources. The OPTIONS method extends this by enabling clients to query a server’s capabilities and allowed actions for specific URLs.

Key Insights

  • HTTP facilitates all internet communication via a request-response model.
  • REST structures web services around resources, accessible and manipulated using standard HTTP methods (e.g., URLs and actions).
  • Common HTTP methods (GET, POST, PUT, DELETE) directly map to CRUD (Create, Read, Update, Delete) operations.
  • The OPTIONS method queries a server about allowed interactions for a URL without affecting data.
  • CORS preflight requests commonly utilize OPTIONS to ensure cross-origin security before full requests are sent.

Technical Details

Understanding HTTP and REST

What is HTTP?

HTTP (Hypertext Transfer Protocol) is the protocol enabling communication between web clients (like browsers) and servers. It operates on a request-response model: a client sends a request, and the server returns a response.

Example: A browser requests a webpage:

GET /homepage HTTP/1.1

The server responds with the page’s content.

What is REST?

REST (Representational State Transfer) is an architectural style for designing networked applications. RESTful services treat data as resources, uniquely identified by URLs. Clients interact with these resources using standard HTTP methods in a stateless manner.

Core RESTful Operations

REST typically maps common data operations to specific HTTP methods:

ActionHTTP MethodPurpose
Read dataGETRetrieve information about a resource
Create new dataPOSTSubmit data to create a new resource
Update dataPUTModify an existing resource completely
Partial UpdatePATCHModify specific parts of an existing resource
Delete dataDELETERemove a specified resource

RESTful API Example: Online Store

Consider a product inventory managed via a RESTful API:

Base URL: https://shop.com/products

Retrieve All Products
  • Method: GET
  • Request:
    GET https://shop.com/products
    
  • Description: Requests a list of all available products.
  • Response:
    [
      { "id": 1, "name": "Keyboard", "price": 20 },
      { "id": 2, "name": "Mouse", "price": 10 }
    ]
    
Add a New Product
  • Method: POST

  • Request:

    POST https://shop.com/products
    Content-Type: application/json
    
    { "name": "Monitor", "price": 150 }
    
  • Description: Submits data to create a new product entry.

Update an Existing Product
  • Method: PUT

  • Request:

    PUT https://shop.com/products/1
    Content-Type: application/json
    
    { "name": "Gaming Keyboard", "price": 30 }
    
  • Description: Replaces the product with ID 1 with the provided data.

Delete a Product
  • Method: DELETE
  • Request:
    DELETE https://shop.com/products/1
    
  • Description: Removes the product with ID 1.

Introducing the HTTP OPTIONS Method

Purpose of OPTIONS

The HTTP OPTIONS method allows a client to discover the communication options supported by the server for a specific URL or resource. It is a “safe” method, meaning it does not retrieve data or modify the server’s state. Its sole purpose is to inquire about server capabilities.

Why Use OPTIONS?

Clients use OPTIONS to determine:

  • Which HTTP methods (e.g., GET, POST, PUT, DELETE) are permitted on a resource.
  • Whether cross-origin requests are allowed (related to CORS).
  • Which request headers the server accepts.

OPTIONS in Action: Online Store Example

To query the capabilities of the product endpoint:

  • Request:
    OPTIONS https://shop.com/products
    
  • Description: Asks the server what actions are allowed on the /products resource.
  • Server Response (Headers):
    Allow: GET, POST, OPTIONS
    Access-Control-Allow-Methods: GET, POST
    Access-Control-Allow-Origin: *
    
  • Interpretation: The server indicates that clients can GET (read), POST (add), and OPTIONS (query capabilities) on this URL. Deletion or updates are not permitted here.

Real-World Application: CORS Preflight Requests

A common use case for OPTIONS is handling CORS (Cross-Origin Resource Sharing) preflight requests. Browsers automatically send an OPTIONS request before certain “non-simple” cross-origin HTTP requests (e.g., POST, PUT, DELETE, or requests with custom headers).

Example: A web page from https://myapp.com attempts to send a POST request to https://api.shop.com/products.

  1. Browser (Automatic Preflight): The browser first sends an OPTIONS request to https://api.shop.com/products.
    OPTIONS https://api.shop.com/products
    Origin: https://myapp.com
    Access-Control-Request-Method: POST
    
  2. Server Response: The API server checks its CORS policy. If the POST request from https://myapp.com is allowed, it responds with:
    Access-Control-Allow-Origin: https://myapp.com
    Access-Control-Allow-Methods: POST, GET, OPTIONS
    
  3. Subsequent Request: Only if the preflight response indicates permission will the browser proceed to send the actual POST request. If blocked, the browser cancels the request.

Search

Find technical notes