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 7: Retrieving Books from our API

Retrieving All Books - Planning

PreviousChapter 7: Retrieving Books from our APINextRetrieving All Books - Implementation

Last updated 3 years ago

Refer back to section for the API endpoint specifications.

1 - Route Name

From the specification, it seems like this will be a GET request that will fetch a collection of books. We can refer back to the sections under chapter 3 for guidelines to follow, specifically the sections and .

The following URI should suffice.

GET /api/v1/books

2 - Input Request

Since this is a GET request, there won't be any input request or payload from the client.

3 - Middleware

This is a public URI, so there really is no need for any middleware.

4 - Validation

Again, since this is just a simple GET request, there won't be any validation needed.

5 - Domain

From the specifications, it looks like we will need the following book entity in our domain layer.

bookModel

  • title

  • description

  • price

  • author

  • datePublished

We will also need some sort of way to query the database to be able to retrieve all the books, getAllBooks() will be the method we'd call.

bookRepository

  • getAll()

On top of that, our controller will call a service, in this case, it will be the bookService which will retrieve all of the books in our database.

bookService

  • getAllBooks()

This is a rough outline of how we are going to be implementing these functions, we'll take a deeper dive at the implementations in the next section of this chapter.

6 - Events

Judging from the specifications, there doesn't seem to be any events, so we'll leave this blank as well.

7 - Response

We'll be adding in these fields:

  • title

  • description

  • price

  • author

  • datePublished

for each of our book listings.

{
    "status": "success",
    "code": 200,
    "message": "List of all books in the database."
    "data": [
        {
            "id": "61f88350745d83158f3c746d",
            "title": "Harry Potter and the Goblet of Fire",
            "description": "Mint condition, but will negotiate",
            "price": 99,
            "author": "J.K. Rowling",
            "datePublished": "Sun Oct 10 2021 23:56:34 GMT-0400"
        },
        ...
    ],
    "errors": null
}

As mentioned previous, we will be .

Method Verbs
URI Design
"Using a Consistently Wrapped Response"
Chapter 6, The Bookstore API Endpoint Specifications, API Endpoint #5: Retrieve All Book Listings