RESTful Node.js: A Structured Approach
  • Book Cover
  • About the Author
  • Links and Resources
  • Part I: The Why
    • Foreword
    • Preface
    • Chapter 1: Introduction
      • The Rise of REST and Distributed Systems
      • Problem #1: Structureless Design, Structureless REST
      • The Emergence of JavaScript and Node.js
      • Problem #2: Structureless JavaScript, Structureless Node.js
      • Behold, the Solution: A Structured Approach
      • Summary
  • Part 2: The Theory
    • Chapter 2: REST Origins
      • A Brief History of the Web and the Birth of REST
      • REST vs. HTTP
      • REST - The Abstract Web Architecture
      • HTTP - A Peak at REST's Concrete Implementation
      • What does it mean for an API to be RESTful?
      • Measuring "RESTfulness" with Richardson Maturity Model
      • Pragmatic REST vs Dogmatic REST
      • Summary
    • Chapter 3: RESTful API Design Guidelines and "Best Practices"
      • Theories vs. Principles vs. Guidelines
      • URI Design
      • Method Verbs
      • Status Codes
      • Representational Design
      • Metadata Design
      • Versioning Strategies
      • Security Considerations
      • Documentation
      • Case Study: GitHub
      • Summary
    • Chapter 4: Structured JavaScript Architecture
      • The Monstrous Monolith and Its Downfall
      • Layered/N-Tier Architecture: The Unpopular Proven Way
      • Microservices and Distributed Computing: A Popular Misdirection
      • Summary
    • Chapter 5: The 8 Step Recipe
      • Route Name (URI)
      • Input Request
      • Middleware
      • Validation
      • Domain
      • Events
      • Output Response
      • Test, Refactor, Document
      • Summary
  • Part 3: The Code
    • Chapter 6: Introduction to the Bookstore API
      • The Bookstore API Endpoint Specifications
      • API Design and Code Structure
      • Project Setup
      • Summary
    • Chapter 7: Retrieving Books from our API
      • Retrieving All Books - Planning
      • Retrieving All Books - Implementation
      • Retrieving A Book By ID - Planning
      • Retrieving A Book By ID - Implementation
      • Summary
    • Chapter 8: Adding Authentication to our API
      • Registering the User - Planning
      • Registering the User - Implementation
      • Logging the User In - Planning
      • Logging the User In - Implementation
      • Getting Authenticated User - Planning
      • Getting Authenticated User - Implementation
      • Summary
    • Chapter 9: Adding the Create, Update, and Delete Operations to our API
      • Creating A Book Listing - Planning
      • Creating A Book Listing - Implementation
      • Updating A Book Listing By ID - Planning
      • Updating A Book Listing By ID - Implementation
      • Deleting A Book Listing By ID - Planning
      • Deleting A Book Listing By ID - Implementation
      • Summary
    • Chapter 10: Testing our API
      • Testing the Request
      • Testing the Middleware
      • Testing the Validation
      • Testing the Domain
      • Testing the Event
      • Testing the Response
      • Testing the Controller
      • Integration Test
      • Summary
  • Conclusion
    • Final Words
  • Bonus!
    • Refactoring to HATEOAS
  • Appendix
    • Sources & References
Powered by GitBook
On this page
  • 1 - Route Name
  • 2 - Input Request
  • 3 - Middleware
  • 4 - Validation
  • 5 - Domain
  • 6 - Events
  • 7 - Response
Edit on GitHub
  1. Part 3: The Code
  2. Chapter 9: Adding the Create, Update, and Delete Operations to our API

Deleting A Book Listing By ID - Planning

PreviousUpdating A Book Listing By ID - ImplementationNextDeleting A Book Listing By ID - Implementation

Last updated 3 years ago

Refer back to section for the API endpoint specifications.

1 - Route Name

Finally, our final API endpoint. For the delete a book by ID, it will be very similar to updating.

We'll just use DELETE instead of PUT as our method verb of choice.

DELETE /api/v1/books/:id

2 - Input Request

None.

3 - Middleware

This will be the exact same as the last section.

For the first layer, we'll be reusing our isAuthenticated helper that will protect us from unauthenticated user from accessing this endpoint.

For the second layer, we'll be reusing our bookPermission helper to verify that the requested book ID exists and that the currently authenticated user is in fact the owner of it.

4 - Validation

None.

5 - Domain

Just like the last section, we'll built on top of the previous section and use the bookModel.

We'll also need some sort of way to make a query to the database in order to find the existing book and delete it, so we'll use the bookRepository layer and add the method deleteById() to do so.

bookRepository

  • deleteById()

On top of that, our controller will call a service to deleteBookById(), in this case, it will be the bookService which will use the bookRepository layer.

bookService

  • deleteBookById()

6 - Events

None.

7 - Response

Again, very similar to the previous section, except there will be 3 possible responses that can be output with this endpoint.

The first is the authentication middleware that we'll be reusing.

{
  "status": "error",
  "code": 401,
  "message": "Access denied: you must be logged in to access this API endpoint.",
  "data": null,
  "errors": ["You must be logged in."]
}

The second is whether or not the client has inputted an existing book ID.

{
    "status": "error",
    "code": 404,
    "message": "That book with the specified ID does not exist."
    "data": null,
    "errors": [
        "Book listing not found."
    ]
}

The third is the successful scenario. Do keep in mind that since we are using a DELETE request, so won't be returning any representation back.

{
  "status": "success",
  "code": 200,
  "message": "The book has successfully been deleted.",
  "data": {},
  "errors": null
}
Chapter 6, The Bookstore API Endpoint Specifications, API Endpoint #9: Delete a Book Listing