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
Edit on GitHub
  1. Part 2: The Theory

Chapter 5: The 8 Step Recipe

In this chapter, we will take what we learned in chapters 3 and 4, and combine them into what I call a 7 (+3) step recipe to creating any API endpoint.

We'll be extending the layered architecture as discussed previously by going over the middleware layer, the validation layer, and the event layer in this chapter.

But wait… what is this extra +3 step in the brackets? This is an extra 3 sub-steps that do not pertain to building the actual endpoint itself, but rather help solidify and strengthen your endpoint if you so choose to add it. The 3 sub-steps are Test, Refactor, and Document.

For simplicity sake, let's just group those last 3 sub-steps in 1 step, and call this "The 8 Step Recipe" from this point forward.

This 8 step recipe is essentially a formal design document, its purpose is to help you plan out your API endpoints before writing any code. It's a checklist of considerations when designing each layer of your endpoint. Think of this as a nice starter template for helping you to design and structure your endpoint and codebase.

This is the 7 (+3) step process that I have been using for the last 5+ years of my career and is something that has not only benefited me during solo projects, but it has also benefited many of the teams I have worked on when using this approach.

Here are some key benefits from using my 8 step recipe.

  1. It takes away the anxiety and pressure of feeling like you might be missing something because it gives you a list of common considerations to think about beforehand.

  2. Having a structured approach keeps you level-headed and clear about the design and structure of your API and code.

  3. Having a methodical way of planning your endpoint let's you break the problem down and see where and what you need to work on.

  4. You remember what you were thinking because you wrote it down; you can then reference it later.

  5. Not only do you have a better understanding of the API endpoint, your team members will understand your thought process as well.

  6. It will save you a ton of time (trust me), which means less tech debt in the future.

Here… is the 8 step recipe to creating any API endpoint.

  1. Route Name (URI)

  2. Input Request

  3. Middleware

  4. Validation

  5. Business logic

  6. Events

  7. Output Response

  8. Test, Refactor, Document

We will be going over each concept carefully in this chapter, and I will be explaining briefly what each component is and go over some real world applications. In the next chapter, we will begin to apply these concepts in building our web API.

This model or concept can be applied to any framework or language. This is supposed to be a framework and language agnostic blueprint so that you may apply this to any project you work on in the future.

PreviousSummaryNextRoute Name (URI)

Last updated 3 years ago