Understanding HTTP, REST, and the OPTIONS Method

January 15, 2026

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:

Action	HTTP Method	Purpose
Read data	GET	Retrieve information about a resource
Create new data	POST	Submit data to create a new resource
Update data	PUT	Modify an existing resource completely
Partial Update	PATCH	Modify specific parts of an existing resource
Delete data	DELETE	Remove 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.

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
```
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
```
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.

Tags: