Back to Blog
Lesson 3 of the REST API Design: Design Your First Clean REST API course
API ArchitectureJuly 14, 20264 min read

Introduction to HTTP Methods: Mastering CRUD in REST APIs

Learn how to use HTTP Methods like GET, POST, PUT, and DELETE to perform CRUD operations. Master the foundation of REST API design for predictable services.

RESTHTTPAPI DesignBackendCRUD

Previously in this course, we explored the Client-Server Architecture and the importance of Statelessness in REST. Now that we understand how clients and servers communicate without holding onto state, we need a standard way to tell the server what we want to do with our data.

In RESTful systems, we use HTTP Methods (also called verbs) to define the action we want to perform on a resource.

From Database Operations to HTTP Methods

If you are coming from a database background, you are likely familiar with CRUD: Create, Read, Update, and Delete. In REST, we map these database operations directly to HTTP methods. By using these consistently, your API becomes intuitive; a developer using your API will know exactly what a request does just by looking at the verb.

The CRUD-HTTP Mapping Table

OperationHTTP MethodIntent
CreatePOSTCreate a new resource
ReadGETRetrieve a resource or collection
UpdatePUTReplace (or update) a resource
DeleteDELETERemove a resource

Breaking Down the Verbs

  • GET: Used to request data from the server. It should be "safe," meaning it only retrieves data and should never change the state of your database.
  • POST: Used to send data to the server to create a new resource. Every time you send a POST request to a collection endpoint (like /tasks), you are telling the server to create something new.
  • PUT: Used to replace an existing resource with new data. If you have a specific task, PUT updates it entirely.
  • DELETE: Does exactly what it says—it removes the resource identified by the URI.

Worked Example: Managing a Task API

Imagine we are building our Task Manager project. We aren't writing the full code yet, but we are defining the "contract" for how our API will function.

If a client wants to interact with a task with the ID 123, the HTTP methods would look like this:

  1. Read the task: GET /tasks/123 The server returns the details of task 123.

  2. Create a new task: POST /tasks The client sends the task details in the body; the server creates it and returns the new ID.

  3. Update the task: PUT /tasks/123 The client sends the full updated task object to overwrite the existing one.

  4. Delete the task: DELETE /tasks/123 The server removes task 123 from the database.

Hands-on Exercise

To solidify this, grab a piece of paper or a text editor. Imagine you are designing an API for a Library System. You have a resource called books.

Write down the HTTP method and the URI you would use for these four scenarios:

  1. Fetching a list of all books in the library.
  2. Adding a new book entry to the library.
  3. Updating the status of a specific book (e.g., changing it from "Available" to "Checked Out").
  4. Removing a book that has been permanently damaged from the system.

(Self-check: Your URIs should look like /books or /books/{id}.)

Common Pitfalls

  • Using GET for actions: A common beginner mistake is using GET to delete or update data (e.g., /delete-task?id=123). Never do this. GET requests are often cached by browsers or proxy servers, which could lead to accidental deletions.
  • Using POST for everything: Some APIs use POST for every operation. This violates the REST principle of using meaningful verbs, making your API harder for others to debug and understand.
  • Ignoring Semantics: Just because you could technically use POST to delete a resource doesn't mean you should. Stick to the standard mapping to keep your API predictable.

FAQ

Q: Are there other HTTP methods? A: Yes, there are others like PATCH (for partial updates), HEAD, and OPTIONS. We will cover PATCH in a later lesson when we discuss updating resources.

Q: Does the server force me to use these methods? A: HTTP is a protocol. While the server doesn't "break" if you use the wrong method, a well-designed API follows these conventions to ensure compatibility with standard tools, security scanners, and caching layers.

Q: What if I need to do something that isn't CRUD? A: REST is resource-oriented. If an action doesn't fit neatly into CRUD, try to think of it as a state change on a resource (e.g., a "Publish" action might be a PUT request to update a status field to published).

Recap

We’ve established that REST APIs rely on a clear mapping between CRUD operations and HTTP methods. Using GET, POST, PUT, and DELETE correctly makes your API predictable, cacheable, and professional. In the next lesson, we will dive deeper into the specific semantics of GET and POST to ensure you are using them safely and effectively.

Up next: GET and POST Semantics

Similar Posts