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
  • Relating HTTP to REST
  • 1. Client-server
  • 2. Layered System
  • 3. Cache
  • 4. Stateless
  • 5. Code-On-Demand (Optional)
  • 6. Uniform Interface
Edit on GitHub
  1. Part 2: The Theory
  2. Chapter 2: REST Origins

HTTP - A Peak at REST's Concrete Implementation

PreviousREST - The Abstract Web ArchitectureNextWhat does it mean for an API to be RESTful?

Last updated 3 years ago

HTTP is the protocol that allows for sending documents back and forth on the web. A protocol is a set of rules that allow for messages can be exchanged between two or more systems. A common protocol for example, is POP3, which is used to retrieve email from mail servers.

In HTTP, there are two different roles: the client and the server. In general, the client always initiates with a request and the server replies with a response. HTTP is text based; that is, messages are essentially bits of text, although the message body can also contain other media. Text usage makes it easy to monitor an HTTP exchange.

The HTTP request messages made by the client are made of a verb, a header, and a body. You may already be familiar with the verbs: GET, POST, PUT, DELETE, PATCH, and so on. The header contains metadata that describes the entire message. The body is where all the contents are stored.

For the HTTP response messages, they are made up of a status code, a header, and a body. Status codes range anywhere from the 100s to the 500s representing success to failures, they are an extra layer of metadata essentially.

HTTP's Request - Response Cycle.

Relating HTTP to REST

In the previous section of the book, we went over the 6 categories of constraints of REST. Essentially, any protocol that adheres to those constraints would be considered to having a REST-based architecture. We will go over each of those constraints and see just how much HTTP innately adheres to them.

1. Client-server

This is a simple one, we just looked at how HTTP has this request-response type of behavior, therefore the first constraint has been met.

2. Layered System

There are many different layers that are in between HTTP. As stated previously: concrete examples are a cache layer, an API gateway layer, and a load balancer. This constraint has now been met too.

3. Cache

In HTTP/1.1, we have mechanisms like 'ETag' and 'Cache-Control' which are built into HTTP. This means this constraint has been met also.

4. Stateless

HTTP is stateless because each request is executed independently, without any knowledge of the requests that were executed before it, which means once the transaction ends, the connection between the browser and the server is also lost. So this would also mean that the stateless property is met as well.

5. Code-On-Demand (Optional)

Nothing to say here, this was optional, so let's leave it at that XD.

6. Uniform Interface

And now... we move on to the most interesting constraint, uniform interface. In order to satisfy this constraint, we must first break it down to its four sub-constraints.

6.1. Identification of resources

How do we identify resources in HTTP? We use URIs.

6.2. Manipulation of resources through representations

Are we able to manipulative resources? Yes, we have metadata in the header to change to different formats like JSON or XML.

6.3. Self-descriptive messages

Same as above, we can use the metadata to manipulative information that can describe the message in different ways.

6.4. Hypermedia as the engine of application state (HATEOAS)

Now comes the tricky part, hypermedia. This essentially is where we, the developers, have to put in our effort to make our API truly RESTful. We will look more into this in the next section, but do note that this is the only (sub)constraint that HTTP does not provide with us out of the box.