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 8: Adding Authentication to our API

Getting Authenticated User - Planning

PreviousLogging the User In - ImplementationNextGetting Authenticated User - Implementation

Last updated 3 years ago

Refer back to section for the API endpoint specifications.

1 - Route Name

Now things are starting to get interesting, because recall that we just broke for our login route. Is it time to do the same thing here as well?

Well if you were thinking of doing something like this... GET /api/v1/auth/user, you, would not be the only one.

Remember what talked about? Always think of the URIs as resources and entities that we can fetch. In this case, I think it's best to create the URI as follows.

GET /api/v1/users/auth

This would suffice many different guidelines we proposed in chapter 3. This would let us think of users as the resource, which means it would then be pluralized. This would also let us have the option of creating a dynamic URI such as this, GET /api/v1/users/:user_id in the future if we were to extend this endpoint.

2 - Input Request

None.

3 - Middleware

We are finally ready to write our first middleware!

For this endpoint, I'm thinking we should write a basic auth middleware that will check if there exists an authenticated user currently.

If the current user is not logged in, then return a response with a 401 status code. Otherwise, business as usual, the request will go through.

4 - Validation

None.

5 - Domain

You'll see in the next section that since we are using Express and the express-session library, fetching the currently authenticated user is quite simple, there's no real reason to make any database calls.

6 - Events

None.

7 - Response

There are two possible responses from this endpoint.

The first is if the user is not logged in. This will be caught somewhere in our middleware. For future use cases, we will be using the same middleware for creating, updating, and deleting a book listing.

{
  "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."]
}

And if the user is logged in, we will get the user's information in the response.

{
  "status": "success",
  "code": 200,
  "message": "The currently authenticated user's information.",
  "data": {
    "first_name": "Yichen",
    "last_name": "Zhu",
    "email": "yichen@yichen.com",
    "phone_number": "1234567890"
  },
  "errors": null
}
Guideline #4: Avoid actions and verbs in the URI in chapter 6, URI Design, URI Path Design
Chapter 6, The Bookstore API Endpoint Specifications, API Endpoint #4: Get Authenticated User