Mastering RESTful Architecture: From Resources to OAuth Authentication

In the era of mobile internet and technologies like Docker, the concept of microservices and RESTful architecture has become widely adopted. This article shares the author’s understanding of RESTful architecture and invites discussion.

1. RESTful Architecture Style

RESTful architecture was first proposed by Roy T. Fielding in his 2000 doctoral dissertation. HTTP is a typical application of this style. Since its inception, it has been favored for its scalability and simplicity, becoming the standard for enterprise‑level services, especially with the rise of cloud and mobile computing.

REST stands for Representational State Transfer. Its main characteristics are resources, a uniform interface, URIs, and statelessness.

1.1 Characteristics of RESTful Architecture

1.1.1 Resource

A resource is an entity or piece of information on the network—text, image, song, service, etc. It can be represented in various formats such as plain text, HTML, XML, binary, or JSON (the most common).

In practice, a resource is a user‑oriented dataset carried by a representation (e.g., JSON). Common representations are JSON (recommended) and XML (not recommended).

Resources are always displayed via a representation, i.e., serialized information.

Typical representations are JSON (preferred) or XML (less preferred).

Representation is the presentation layer of REST.

Data (especially in databases) is a more abstract, computer‑friendly form that resides in the logical model.

The relationship between resource and data is illustrated below:

1.1.2 Uniform Interface

REST defines CRUD operations (Create, Read, Update, Delete) using HTTP methods: GET (SELECT): Retrieve one or more resources. POST (CREATE): Create a new resource. PUT (UPDATE): Replace an existing resource (client provides the full representation). PATCH (UPDATE): Modify part of a resource. DELETE (DELETE): Remove a resource.

1.1.3 URI

Each resource can be identified by a URI; accessing that URI retrieves the resource. Typically, the URI is a URL.

1.1.4 Stateless

Statelessness means each request contains all the information needed to process it, independent of previous interactions. For example, retrieving an employee’s salary via a single URL is stateless, whereas a multi‑step login process is stateful.

1.2 ROA, SOA, REST and RPC

ROA (Resource Oriented Architecture) focuses on resources and is essentially the RESTful style. While ROA and SOA can coexist, RPC is another SOA variant. Historically, RPC (based on XML‑RPC and later SOAP) required specific protocols and client languages, making it less suitable for mobile environments. REST, using JSON or XML over HTTP, decouples client implementation from server technology, leading to its dominance.

Comparisons between RPC and REST are shown in the diagram below:

1.3 Pure REST vs Hybrid Style

Implementations can be classified as pure REST or hybrid. Pure REST adheres strictly to the four principles described earlier. Hybrid implementations borrow some REST principles (e.g., using GET for retrieval) but may rely on POST for creation, modification, or deletion, often due to legacy RPC services wrapped with a REST‑like façade. The author advises avoiding hybrid style when possible.

2. Authentication Mechanisms

Because RESTful services are stateless, authentication is crucial to protect private resources. Authentication identifies the user; authorization determines what actions the user may perform.

2.1 Basic Auth

HTTP Basic authentication (BA) implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session identifier and login pages. Rather, HTTP Basic authentication uses static, standard fields in the HTTP header which means that no handshakes have to be done in anticipation.

Basic Auth is simple but exposes credentials, so it is rarely used in production for public APIs.

2.2 Token Auth

Token Auth sends a pre‑generated token instead of username/password. It requires a server‑side token management system, adding complexity and often being less widely adopted.

2.3 OAuth

OAuth is an open standard for authorization. OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third‑party access to their server resources without sharing their credentials. Designed specifically to work with HTTP, OAuth essentially allows access tokens to be issued to third‑party clients by an authorization server, with the approval of the resource owner.

OAuth enables users to grant limited access to their data without sharing passwords. OAuth 2.0 improves security and reduces client‑side complexity, and is the recommended authentication method for RESTful services.

3. Summary

Pure REST combined with OAuth is the standard for microservices.

Basic Auth should only be used in development environments.

Design resources thoughtfully.

Use the correct HTTP method for each operation.