Express.js Mastery / Express: Let’s Start Building The Natours API!

Handling PATCH Requests

📌 Updating Existing Data

After implementing GET and POST, the next step is handling PATCH requests to update existing data.

🔄 PUT vs PATCH

Method

Description

PUT

Replaces the entire resource.

PATCH

Updates only the specified fields.

✅ Why use PATCH?

  • ✏️ Only the changed fields need to be sent.

  • 👤 Simpler for the client since they don't have to send the entire object.

  • 🚀 This approach also works well with databases like MongoDB/Mongoose, which we'll use later.

📌 In this course, we'll implement PATCH only.

🛣️ Route Structure

  • 🌐 URL: api/v1/tours/:id

  • Needs the tour's ID in the URL (like the earlier GET-single-tour route) so the app knows which tour to update.

🔹 Step 1: Why the actual update logic isn't implemented

Since this app is just testing API concepts using a JSON file (not a real database), fully implementing the update would mean:

  1. 📖 Reading the tour from the JSON file

  2. ✏️ Modifying it

  3. 💾 Saving the whole file back

🚫 That's unnecessary extra work for what this section is teaching.

🎯 The real focus here is:

  • 🌐 Understanding HTTP verbs (GET, POST, PATCH, DELETE)

  • 🔢 Understanding proper status codes (e.g., 201 for created, 200 for success, 400/404 for errors)

  • 📦 Understanding the correct response structure/format

🔹 Step 2: Writing the PATCH handler

app.patch('/api/v1/tours/:id', (req, res) => {
  if (req.params.id * 1 > tours.length) {
    return res.status(404).json({
      status: 'fail',
      message: 'Invalid ID'
    });
  }

  res.status(200).json({
    status: 'success',
    data: {
      tour: '<Updated tour here...>'
    }
  });
});

💡 Why each part works:

  • 🔢 req.params.id * 1 — converts the string ID from the URL into a number (same trick used in the GET-single-tour route)

  • ✅ ID validation check — reused logic from before: if the ID is out of range, respond with 404 Not Found and a fail status

  • 🟢 200 status — correct code for a successful update (unlike 201, which is only for newly created resources)

  • 📦 The response still follows the same JSON envelope pattern: status + data

  • 📝 Since there's no real update logic, a placeholder string ('Updated tour here...') stands in for what would normally be the actual updated tour object

🔹 Step 3: Testing in Postman

  • 💾 Save the existing Get request

  1. 📋 Duplicate the existing "Get Tour" request.

  2. 🔄 Change the method to PATCH.

  3. 💾 Save it as "Update Tour" (shown in a distinct gray text in the sidebar to mark it apart from other saved requests).

  • 📦 Add a request body → Body → raw → JSON:

image.png
{
  "duration": 15
}

  • ✅ Send it targeting tour ID 3 → response returns the placeholder "Updated tour here..." with status 200.

  • ❌ Test again with an invalid ID → response returns "fail" / "Invalid ID" with status 404.

  • 💾 Save the request again so the body content persists for later use.

⚠️ Note: Since the update logic isn't implemented, sending this request doesn't actually change any data — it just confirms the route, status codes, and response shape work correctly.

✅ Key Takeaway

  • 🩹 PATCH is used for partial updates (only changed fields); 📦 PUT is used for full-object replacement — this app uses PATCH.

  • 🟢 The response for a successful update uses status 200, not 201 (that's reserved for creation).

  • ♻️ ID validation logic from the GET-single-tour route is reused here — a recurring pattern for any route needing a specific tour by ID.

  • 🎯 The actual "update the file" logic is intentionally skipped since the focus is on HTTP methods, status codes, and response formatting, not file-based persistence.

⏭️ What's Next

  • 🗑️ Only DELETE remains to complete the full CRUD set (Create, Read, Update, Delete).