Settings
Fast Delivery
Free Shipping
Incoterms
Payment Types
Marketplace Product
The Basics of REST APIs for Makers
2026-03-09 | By Maker.io Staff
Connected devices in IoT projects need a way to exchange information over the internet. As a solution, REST provides a simple, widely adopted architecture that’s ideal for DIY projects. Read on to see how this architecture works, why it benefits makers, and where it can be applied in connected projects.
What is REST?
Representational State Transfer (REST) is a resource-based architectural design pattern that simplifies the process of creating distributed systems. REST is not a protocol itself, but instead relies on established protocols, commonly HTTP, to exchange data over the Internet.
In resource-based architectures, such as REST, each resource is addressable through a uniform resource identifier (URI). Examples of resources include sensor data entries, user profiles, or weather reports. Clients specify how they want to interact with a resource using HTTP methods that allow them to create, read, update, and delete resources.
These resources are accessed via public or secured endpoints. An endpoint is the full web address (URL) used to reach a resource on the server. Public endpoints do not need authentication, while secured ones require clients to prove they may access the resource. Access is typically granted with a token, API key, or through IP whitelisting.
Finally, REST is stateless. This means that the server treats each client request in isolation, and each one must include all the information the server needs to handle it. While this may seem cumbersome to clients, it allows for greater flexibility in the server architecture. Clients don’t need to know how the server processes requests, and each request could be handled by different servers, allowing for better load balancing in high-throughput systems.
The Basics of HTTP Requests
Although REST principles do not depend on a specific protocol or technology, HTTP has become the norm since it provides everything needed to build RESTful services. HTTP methods indicate how a client wants to interact with a resource, URIs identify resources, and status codes communicate whether requests succeeded or failed.
A typical HTTP request consists of a request line, optional headers, and the message payload, separated from the headers by a blank line. For example:
POST /api/v1/person HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 49
{"name": "Alice", "age": 30, "city": "Test Town"}
The first line is the request line. It tells the server what to do (POST), which endpoint to access (the person resource located at /api/v1/person), and which protocol version to use. Headers typically contain metadata to help the server process the request, such as content type, length, or authentication details. In this example, the data is sent to the server as a JSON-encoded object.
The most common operations include creating a resource (POST), reading an existing entry (GET), updating a resource (PUT), and deleting an entry (DELETE). POST and PUT requests usually include a body with the values to store, while GET and DELETE requests typically do not. For example, a client can send the following message to fetch the person with the ID 21746:
GET /api/v1/person/21746 HTTP/1.1 Host: example.com Accept: application/json
Understanding HTTP Server Responses
The server follows a similar layout for its responses. Each valid response begins with a status line that contains the protocol version, a three-digit status code, and a corresponding status description. This is followed by optional headers, similar to the request. Finally, the message body includes the requested data, separated from the headers by a blank line:
HTTP/1.1 200 OK Content-Type: application/json Content-Length: 67 Date: Tue, 04 Nov 2025 18:41:26 GMT
{
"id": 21746,
"name": "Alice",
"age": 30,
"city": "Test Town"
}
Similar to requests, response data is often encoded using JSON. Other common formats include plain text, binary data (such as images or PDFs), or entirely custom formats. The Content-Type header typically describes the format used by the server.
This example illustrates how clients and servers communicate and why each request must be completely self-contained, as keeping the state synchronized between multiple servers would otherwise be difficult.
Common HTTP Status Codes and What They Mean
Status codes indicate whether the server successfully handled a request (2xx) or encountered problems (400–599). Common success codes include 200 (OK), 201 (resource created), and 204 (the request succeeded but there was no data to return). Codes 301 and 302 let the client know that the resource has moved to a new location. Codes in the range 400 to 499 indicate client errors:
- 400: The request was incorrect, incomplete, or malformed.
- 401: The resource requires authentication, but no credentials were provided.
- 403: The client is authenticated but not allowed to perform the operation.
- 404: The requested resource was not found.
Lastly, the 500 status code indicates that the server encountered an internal error while processing the request.
Benefits and Drawbacks of REST Interfaces
The benefits of REST include its wide support and easy-to-debug architecture. Its popularity means that ready-made frameworks exist for many common programming languages and platforms, such as Flask (Python), Spring Boot (Java), and Rails (Ruby). This high compatibility allows you to work without special hardware or deep knowledge of communication protocols and server architectures.
REST can introduce overhead from HTTP and TCP/IP, and HTTPS adds extra processing that may be problematic for some streamlined embedded devices. The architecture was not designed to handle partial data. Clients cannot request single values, like a user’s name, but must retrieve the entire user profile. Additionally, the stateless nature of REST can require multiple requests, which may reduce efficiency.
Summary
Connected devices in IoT projects need a way to exchange information over the internet, and REST provides a simple, widely adopted architectural pattern. REST is stateless, meaning each request must contain all information needed for the server to process it. This allows flexible server architectures and load balancing, but may require multiple requests for related data. The architecture leverages established protocols, commonly HTTP, to let clients interact with resources, each identified by a URI.
HTTP requests and responses follow a structured layout with a request or status line, headers, and an optional body. Data is often encoded in JSON, though plain text or binary files. Status codes communicate success, failure, or redirection.
While REST is widely supported, easy to debug, and compatible with most platforms and frameworks, it can add overhead from HTTP and TCP/IP. It further does not support partial data requests, forcing clients to retrieve complete resources even when they only need a subset.
Australia