home / skills / copyleftdev / sk1llz / fielding

fielding skill

/domains/api-design/fielding

This skill helps you design durable REST APIs by applying Fielding's constraints to ensure statelessness, hypermedia, caching, and uniform interfaces.

npx playbooks add skill copyleftdev/sk1llz --skill fielding

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.0 KB
---
name: fielding-rest
description: Design network-based software architectures using Roy Fielding's REST principles. Emphasizes the constraints of the web—statelessness, cacheability, uniform interfaces, and HATEOAS. Use when designing web APIs that must endure for decades.
---

# Roy Fielding Style Guide

## Overview

Roy Fielding (creator of REST and HTTP co-author) defines the architectural style that powers the World Wide Web. His philosophy is about **architectural constraints** that induce properties like scalability, visibility, and modifiability. True REST is not just JSON over HTTP; it is about decoupling the client from the server through a uniform interface and hypermedia.

> "A REST API should not be dependent on any single communication protocol, though its successful mapping to HTTP is why it is famous."

## Core Principles

1.  **Uniform Interface**: Resources are identified by URIs, and manipulation happens via standard representations (HTML, JSON).
2.  **Statelessness**: Every request must contain all context necessary to understand it. The server stores no session state.
3.  **Cacheability**: Responses must define themselves as cacheable or not to improve network efficiency.
4.  **HATEOAS (Hypermedia as the Engine of Application State)**: The client navigates the API via links provided dynamically by the server, not by hardcoding URL structures.
5.  **Layered System**: The client cannot tell if it is connected directly to the server or an intermediary (CDN, load balancer).

## Prompts

### Design a True REST API

> "Act as Roy Fielding. Critique this API design.
>
> Focus on:
> *   **Noun-Verbs**: Are they using POST to 'get' data? Are they tunnelling RPC through HTTP?
> *   **Hypermedia**: Does the response include links (`_links`, `Link` header) to related resources?
> *   **Caching**: Are `Cache-Control` headers used correctly?
> *   **Status Codes**: Are they using 200 OK for errors? Are they using 201 Created?"

### Architectural Review

> "Evaluate this system architecture against REST constraints.
>
> Questions to ask:
> 1.  Is the server storing session state (violates Statelessness)?
> 2.  Are the clients coupled to the internal DB ID structure (violates Uniform Interface)?
> 3.  Can we insert a caching proxy without breaking the client (Layered System)?
> 4.  If I change the URL of a resource, will the client break (Violates HATEOAS)?"

## Examples

### The Richardson Maturity Model (Level 3 - Glory of REST)

#### Request
```http
GET /accounts/12345 HTTP/1.1
Host: bank.example.com
Accept: application/vnd.bank.account+json
```

#### Response
```http
HTTP/1.1 200 OK
Content-Type: application/vnd.bank.account+json
Cache-Control: public, max-age=3600
Link: <https://bank.example.com/docs/account>; rel="profile"

{
  "account_number": "12345",
  "balance": {
    "currency": "USD",
    "value": 100.00
  },
  "status": "active",
  "_links": {
    "self": {
      "href": "/accounts/12345"
    },
    "deposit": {
      "href": "/accounts/12345/deposit",
      "method": "POST"
    },
    "withdraw": {
       "href": "/accounts/12345/withdraw",
       "method": "POST"
    },
    "details": {
       "href": "/accounts/12345/transactions",
       "method": "GET"
    }
  }
}
```
*Note the `_links` section. Ideally, the client only knows the entry point (`/`) and navigates entirely via these links.*

### Anti-Patterns (What NOT to do)

*   **RPC style**: `POST /updateUser?id=123`.
*   **Ignoring Semantics**: Using `GET` to delete data.
*   **API Versioning in URL**: `/v1/users` (Fielding argues versioning should be in the Media Type `Accept: application/vnd.myapi.v1+json`).
*   **No Hypermedia**: Returning just `{ "id": 1, "name": "bob" }` without context on what can be done with "bob".

## Resources

*   [Architectural Styles and the Design of Network-based Software Architectures (Fielding's Dissertation)](https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
*   [REST APIs must be hypertext-driven (Fielding's Blog)](https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)

Overview

This skill helps you design network-based software architectures using Roy Fielding's REST principles. It emphasizes the web constraints that yield scalability, modifiability, and visibility: statelessness, cacheability, uniform interfaces, layered systems, and HATEOAS. Use it to critique API designs and produce architectures meant to endure for decades.

How this skill works

I inspect API designs and system architectures against Fielding's constraints, looking for violations like session state on the server, RPC tunnelling over HTTP, missing hypermedia, incorrect cache semantics, and improper status-code usage. I recommend concrete fixes: resource-first modeling, media-type versioning, explicit Cache-Control and Link headers, and embedding HATEOAS links so clients navigate via hypermedia. I also evaluate whether intermediaries (CDNs, proxies) can be inserted without breaking clients.

When to use it

  • Designing public or long-lived web APIs that must remain stable and evolvable
  • Performing architectural reviews for web services or microservices
  • Migrating RPC-style APIs to resource-oriented RESTful designs
  • Defining API contracts and media types for backward-compatible evolution
  • Optimizing APIs for caching and intermediate layers

Best practices

  • Model APIs as resources (nouns) and use standard HTTP verbs for actions
  • Make every request self-descriptive; avoid server-side sessions and opaque client coupling
  • Return explicit caching headers and use content negotiation with media types for versioning
  • Provide HATEOAS links in responses so clients discover actions and URIs dynamically
  • Use proper HTTP status codes and Link headers for documentation and relations

Example use cases

  • Critique an existing API and get a prioritized list of REST constraint violations and fixes
  • Design a new Level-3 REST API with media-type versioning and full hypermedia controls
  • Audit system architecture for session-state leakage and recommend stateless alternatives
  • Create response schemas that include _links and Cache-Control headers to enable caching proxies
  • Convert RPC-style endpoints into resource-oriented endpoints and migration steps

FAQ

Does following Fielding's REST require using HTTP only?

No. REST is an architectural style independent of any single protocol, though HTTP is its most common mapping and I focus on applying Fielding's constraints to HTTP APIs.

How do I version an API without breaking clients?

Prefer media-type versioning (Accept/Content-Type) and evolve representations while keeping entry points stable; use hypermedia so clients discover capabilities rather than hardcoding URLs.

Is HATEOAS required for all APIs?

For long-lived, evolvable public APIs, yes—HATEOAS decouples clients from URL structures. For internal or short-lived services, pragmatic trade-offs may apply.