Understanding REST and HTTP Methods

1. From Web Pages to APIs: A New Way to Communicate

So far, you've used PHP to generate HTML pages that are sent to a browser. An API (Application Programming Interface) works on a similar client-server model, but instead of sending visual HTML, the server sends raw data, usually in a structured format like JSON. This allows different applications (like a mobile app, a JavaScript front-end, or even another server) to use your PHP backend's logic and data.

REST (REpresentational State Transfer) is the most popular architectural style for designing these APIs. It's not a strict protocol but a set of guiding principles that make APIs scalable, stateless, and easy to use.

To get a quick overview, let's watch the first couple of minutes of this video from ByteByteGo.

The key idea here is that a REST API exposes resources. A resource is any piece of data in your system: a user, a blog post, a product, etc. Each resource is identified by a unique URL (or URI, Uniform Resource Identifier). For example:

• A collection of all users might be at /users.
• A specific user might be at /users/123.

But how do we tell the server what we want to do with that resource? That's where HTTP methods come in.

2. The Language of REST: HTTP Methods

You are already familiar with GET and POST from handling web forms. REST leverages these and other standard HTTP methods to perform actions on resources. This maps very cleanly to the CRUD (Create, Read, Update, Delete) operations you know from database management.

Here's the standard mapping:

• GET: Read a resource.
• POST: Create a new resource.
• PUT: Update or replace an existing resource.
• DELETE: Delete a resource.

Let's dive into the specifics of each method. The following article from restfulapi.net provides a clear and detailed explanation.

Key Concepts: Safety and Idempotency

Let's crystallize those two important terms from the article, as they are crucial for professional development and relate to your interest in security and system robustness.

• Safe Method: A method is "safe" if it doesn't change the state (the data) on the server. GET is a safe method. You can request a user's data a thousand times; the user's data itself won't change because of it. Search engine crawlers and caching systems rely on this to work without fear of accidentally modifying data.

• Idempotent Method: A method is "idempotent" if making the same request multiple times has the same effect as making it once.

  • GET, PUT, and DELETE are idempotent. If you send a request to DELETE /users/123 three times, the first call deletes the user, and the next two do nothing (or return a "Not Found" error). The end result is the same: the user is gone.
  • POST is not idempotent. If you send a POST request to /users three times with the same user data, you will create three new, separate users. This is an important distinction to prevent accidental data creation.

Here's a summary table based on the one in the article you read:

3. The Guiding Principles of REST

While using HTTP methods for CRUD is a core part of REST, it's not the whole story. REST is an architectural style defined by several principles. An API that follows these principles is called "RESTful".

The following video provides an excellent breakdown, clearly distinguishing the rules of the HTTP protocol from the architectural principles of REST.

To reinforce those ideas, here is a summary of the core REST principles from the AWS documentation.

Let's briefly summarize the most critical principles for our purposes:

1. Client-Server: The client (who asks for data) and the server (who provides it) are separate. This allows them to be developed and scaled independently. Your PHP backend can serve a web app, a mobile app, and a desktop app, all at the same time.
2. Statelessness: This is a big one. Each request from the client to the server must contain all the information the server needs to understand and process the request. The server does not store any client context between requests. Unlike the session-based web application we just built, a RESTful server doesn't rely on $_SESSION. Authentication is typically handled by sending a token with every single request.
3. Uniform Interface: This is the principle that enforces consistency. It includes using nouns for resource URIs, using HTTP verbs for actions, and providing self-descriptive messages. It's why GET /users is the standard way to fetch users in any RESTful API.

The diagram below shows a simplified view of how these pieces fit together. A client sends an HTTP request (e.g., GET /users/123), which the web service processes, possibly by interacting with a database, before returning a response (typically JSON data).

Conclusion

In this lesson, we've laid the theoretical groundwork for building APIs. You've learned that REST is not a technology, but a set of design principles for creating scalable and easy-to-use web services.

Key Takeaways:

• An API allows applications to communicate by exchanging data, not HTML.
• REST is an architectural style for designing APIs based on resources identified by URIs.
• Standard HTTP methods are used to perform CRUD operations:
  • GET to read.
  • POST to create.
  • PUT to update/replace.
  • DELETE to remove.
• Key principles of REST include client-server separation, statelessness, and a uniform interface.
• Understanding method characteristics like safety and idempotency is crucial for building robust systems.

Preview of the Next Lesson:
Theory is great, but now it's time to write some code. In our next lesson, we will take the first practical step: handling incoming API requests and routing them based on the URL and HTTP method. We'll build a basic router in PHP that can look at a request like GET /posts/5 and know that the client wants to read the post with ID 5.