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
  2. Chapter 2: REST Origins

REST vs. HTTP

PreviousA Brief History of the Web and the Birth of RESTNextREST - The Abstract Web Architecture

Last updated 3 years ago

Two of the most confusing and misunderstood concepts used by everyday web developers are HTTP and REST, because there are developers who have worked for decades in this industry and still do not know the differences between those two. We are going to clear that up before moving onto the details of what REST and HTTP actually are.

REST is an architectural style guideline which enforces the correct use of the HTTP transport protocol. HTTP is a communications protocol that transports messages over a network. The HTTP 1.1 protocol was built to be the ideal protocol to follow the principles and constraints of REST.

One way to look at the relationship between HTTP and REST is that REST is the design, and HTTP 1.1 is an implementation of that design. In reality the two were designed simultaneously.

So are REST and HTTP the same? No, they are not. HTTP stands for HyperText Transfer Protocol and is a way to transfer files. This protocol is used to link pages of hypertext on the world-wide-web. However, there are other transfer protocols available like FTP and . Representational State Transfer, or REST, is a set of constraints that ensure a scalable, fault-tolerant and easily extensible system.

One thing that confuses people, is that REST and HTTP seem to be used hand-in-hand. After all, the world-wide-web itself runs on HTTP, and it makes sense. However, there is nothing in the REST constraints that make the usage of HTTP as a mandatory transfer protocol. It's perfectly possible to use other transfer protocols like SMTP, SMS, or even Bluetooth. An API could use any protocol and could still very well be a RESTful API.

In practice, most - if not all - RESTful APIs currently use HTTP as a transport layer, since the infrastructure, servers, and client libraries for HTTP are widely available already.

Gopher