RESTful API

A RESTful API follows the REST architecture outlined by Roy Fielding in 2000. Rather than inventing new protocols, it maps business objects onto resources and lets standard HTTP methods describe what should happen to them — making interfaces predictable and easy to integrate across services.

REST's Guiding Rules

• Stateless calls: The server never stores client context between requests.
• Client/server split: UIs and backends evolve and scale independently.
• Method semantics: Actions are expressed via GET, POST, PUT, DELETE and friends.
• Caching allowed: Marking responses cacheable trims latency and load.
• Middle layers: Gateways and proxies slot in transparently.

HTTP Verbs

• GET: Read resources; never changes server state.
• POST: Create resources or submit data for handling.
• PUT: Overwrite a resource with the given representation.
• DELETE: Remove a resource.
• PATCH: Modify only part of a resource.

URL Design

URIs identify resources; HTTP methods identify actions. Nesting conveys relationships, and plural nouns denote collections. An example:

• GET /books: Retrieve the book list.
• GET /books/{id}: Retrieve one book.
• POST /books: Insert a new book.
• PUT /books/{id}: Fully update a book.
• DELETE /books/{id}: Erase a book.

HTTP Status Codes

Status codes tell the caller whether a request worked, and why:

• 200 OK: The request succeeded and data follows.
• 201 Created: Creation succeeded.
• 204 No Content: Success, nothing to return.
• 400 Bad Request: Malformed or invalid input.
• 401 Unauthorized: Credentials missing or refused.
• 404 Not Found: No such resource.
• 500 Internal Server Error: An unexpected server fault.

Summary

With its reliance on HTTP standards, REST delivers an interface style that is quick to learn, easy to extend, and robust enough for everything from small services to sprawling platforms.