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 I: The Why

Preface

PreviousForewordNextChapter 1: Introduction

Last updated 2 years ago

The fall of 2014 was when I got my first major breakthrough as a software developer; although I was still in university at the time I managed to land a high-paying contract gig at a local digital agency. I was hired to build a large property management web application. Prior to being hired for this contract my work experience mostly consisted of freelancing and a couple of short-term jobs at startups. At the time I was hired by the digital agency I had just over two years of experience under my belt building real-world professional software. Education and experience aside, I had successfully secured this year-long contract job and I was tasked to lead the development of the entire backend system.

The technology stack for this project was PHP with Laravel and Node.js with Express in the backend along with jQuery, Backbone.js and AngularJS in the frontend. I spent an entire year working on the backend for this project from beginning to end. I initially started building the entire RESTful API on the PHP and Laravel side, but later transitioned to working more on the Node.js side. By the end of the project, I had created a staggering number of API endpoints: over 150. These endpoints included modules for user authentication, permission management, messaging, payment integration, and many more.

Let's take a step back for a moment and summarize the situation: I was a (relatively) new software developer hired to design and develop a complex backend system for a widely-used property management application. At this point, you may be wondering: "So Yichen, how did everything turn out?"

To summarize what that year was like, all I can say is that it was… hell.

I was expected to deliver high-quality software, but instead, I managed to give my boss, my CTO and my client all near-death heart attacks. I was sloppy with my code and I had no idea how to design maintainable software that could scale. Many of my APIs would break unexpectedly, and without proper tests to back them up, I often did lots of manual regression testing to keep my anxiety in check. When it came time to clean up and refactor my code - just kidding, I never cleaned up or refactored code during this period of my career. Don't even ask me about documentation - I didn’t have any.

The chaos and hellishness of that year of work taught me a lot of valuable lessons about backend software development, and it is my hope that this book can help you avoid learning things the hard way and making the same mistakes that I did.

These notes were actually filled with more questions and uncertainties than anything else. In fact, the initial commit to my GitHub repository was called "things-to-learn" and was full of random notes and questions that I had transferred from my Evernote notebook stacks. Some of these questions included:

  1. What is REST (actually)?

  2. What is HATEOAS (really)?

  3. What are the "correct" ways to create REST APIs?

  4. What is the difference between HTTP and REST?

  5. How do you structure a REST API in Node.js?

  6. Where are all the Node.js architecture books?

  7. And many, many more...

And because I was curious, I wanted answers...

My curiosity and desire for answers didn't go away after the conclusion of my difficult project, and I did a lot of research with the intention of trying to answer all of these questions. I was able to compile an exhaustive list of all the things to consider before creating any RESTful APIs, and that list has evolved into the book you’re reading right now. I wrote this book with the goal of answering the questions listed above and clearing up any doubts for Node.js developers as they conceive, build and maintain REST APIs throughout their careers.

I often take notes at work and in my day-to-day life so that I can revisit them later on, and this book actually began as a collection of items that I wrote in my . By the time the property management software was launched I had hundreds of pages of notes written in my notebooks over the course of that year.

Evernote
This is one of the web pages of the property management software I worked on.
March 15, 2015. That was the day I decided to start writing this book.