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
  • API Versioning
  • URI Path
  • Query String Parameters
  • HTTP Verb
Edit on GitHub
  1. Part 2: The Theory
  2. Chapter 5: The 8 Step Recipe

Route Name (URI)

PreviousChapter 5: The 8 Step RecipeNextInput Request

Last updated 3 years ago

The route URI is the entry point in which the client will use to initiate the request for a desired resource. There are 4 considerations when it comes to planning for the URI path.

  1. API Versioning

  2. URI Path

  3. Query String Parameters

  4. HTTP Verb

The anatomy of an HTTP request.

API Versioning

For me personally, I have always used the URI prefixing approach like this: https://example.com/api/v1.

URI Path

Query String Parameters

The final result of your decision should be something like this:

GET /api/v1/users?page=1&limit=10

Which should be very intuitive as it translates to "retrieve a list of the first 10 users in the application".

HTTP Verb

We talked about API versioning strategies under chapter 3, . Whichever strategy(ies) you decide to implore, make to specify it clearly in the design doc.

Next is the URI path itself. Make sure to design the URIs by following the best practices and guidelines mentioned in chapter 3, . Also, make sure to make them as RESTful as possible whilst being as pragmatic as possible.

Similar to the above, try following the best practices mentioned in the section of chapter 3. Make sure to remember that query strings are used mainly as optional parameters.

Similar to the above, try following the best practices mentioned in chapter 3, . Make sure to always utilize the verbs as much as possible without naming the URIs as actions or functional APIs.

Versioning Strategies
URI Design
Method Verbs
URI Query Design