DEV Community

Pranav Bakare
Pranav Bakare

Posted on

HTTP methods

Image description

Here are the most commonly used HTTP methods, explained with examples from a blog application:

1. GET

  • Purpose: Retrieve data from the server.
  • Example: Fetch a list of blog posts or a specific blog post.

Use Case:

  • Get all blog posts:

    GET /api/posts
    

    Response:

    [
      {
        "id": 1,
        "title": "First Blog Post",
        "content": "This is my first post.",
        "author": "John Doe"
      },
      {
        "id": 2,
        "title": "Second Blog Post",
        "content": "This is my second post.",
        "author": "Jane Smith"
      }
    ]
    
  • Get a single blog post:

    GET /api/posts/1
    

    Response:

    {
      "id": 1,
      "title": "First Blog Post",
      "content": "This is my first post.",
      "author": "John Doe"
    }
    

2. POST

  • Purpose: Create new data on the server.
  • Example: Create a new blog post.

Use Case:

  • Create a new blog post:

    POST /api/posts
    Content-Type: application/json
    
    {
      "title": "My New Blog Post",
      "content": "This is the content of my new blog post.",
      "author": "John Doe"
    }
    

    Response (Success):

    {
      "id": 3,
      "title": "My New Blog Post",
      "content": "This is the content of my new blog post.",
      "author": "John Doe"
    }
    

3. PUT

  • Purpose: Update an existing resource completely. Typically, the entire object must be sent with the update.
  • Example: Update the content of an existing blog post.

Use Case:

  • Update an existing blog post:

    PUT /api/posts/1
    Content-Type: application/json
    
    {
      "title": "Updated Blog Post",
      "content": "This is the updated content of the blog post.",
      "author": "John Doe"
    }
    

    Response (Success):

    {
      "id": 1,
      "title": "Updated Blog Post",
      "content": "This is the updated content of the blog post.",
      "author": "John Doe"
    }
    

4. PATCH

  • Purpose: Update part of an existing resource, instead of replacing the entire resource (like PUT).
  • Example: Update only the title of a blog post.

Use Case:

  • Update the title of an existing blog post:

    PATCH /api/posts/1
    Content-Type: application/json
    
    {
      "title": "Partially Updated Blog Post Title"
    }
    

    Response (Success):

    {
      "id": 1,
      "title": "Partially Updated Blog Post Title",
      "content": "This is the content of the blog post.",
      "author": "John Doe"
    }
    

5. DELETE

  • Purpose: Delete a resource from the server.
  • Example: Delete a specific blog post.

Use Case:

  • Delete a blog post:

    DELETE /api/posts/1
    

    Response (Success):

    {
      "message": "Blog post deleted successfully."
    }
    

6. OPTIONS

  • Purpose: Describe the communication options for the target resource. It's used to check which HTTP methods are supported by the server for a given resource.
  • Example: Check which HTTP methods are allowed on blog posts.

Use Case:

  • Request:

    OPTIONS /api/posts
    
  • Response:

    Allow: GET, POST, PUT, PATCH, DELETE
    

7. HEAD

  • Purpose: Similar to GET, but it only retrieves the headers of the response, not the body. Used to check if a resource exists or to retrieve meta-information like content type or length.
  • Example: Check if a blog post exists.

Use Case:

  • Request:

    HEAD /api/posts/1
    
  • Response (headers only):

    HTTP/1.1 200 OK
    Content-Type: application/json
    Content-Length: 345
    

Example Summary for Blog Application:

  • GET: Retrieve blog posts or details of a single blog post.
  • POST: Create a new blog post.
  • PUT: Fully update an existing blog post (e.g., changing both title and content).
  • PATCH: Partially update a blog post (e.g., change only the title).
  • DELETE: Remove a blog post.
  • OPTIONS: Check allowed HTTP methods.
  • HEAD: Check if a blog post exists without retrieving its content.

Each method serves a specific purpose, allowing RESTful APIs to be efficient and maintain the correct behavior across different actions.

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

Top comments (0)

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay