การออกแบบจุดเชื่อมต่อ RESTful API

Welcome! In this lesson, we'll dive into designing clean and efficient API endpoints following REST principles. Understanding REST is crucial for building scalable web services.

REST stands for Representational State Transfer. It's an architectural style for networked applications, emphasizing a stateless client-server communication.

At the heart of REST are resources. Think of resources as any information or data that your API can provide or manipulate. They are the 'things' your API manages.

• A resource is identified by a unique URL (Uniform Resource Locator).
• They are typically represented by nouns, like users, products, or orders.
• Ideally, use plural nouns for collections of resources.

While resources are nouns, the actions you perform on them are indicated by standard HTTP methods (also called verbs). These methods correspond directly to common data operations:

• GET: Retrieve data (Read)
• POST: Create new data (Create)
• PUT: Replace existing data (Update all)
• PATCH: Partially update existing data (Update partial)
• DELETE: Remove data (Delete)

A well-designed endpoint URL should be intuitive and predictable. It typically follows a pattern:

Using a version (like v1) is good practice for future API changes. Always use plural nouns for resource names.

• Good: /api/v1/users
• Bad: /api/v1/getUsers

REST APIs distinguish between a collection of resources and a single resource within that collection:

• Collection URL: Refers to a group of resources. E.g., /users (all users).
• Item URL: Refers to a specific resource. E.g., /users/123 (user with ID 123).

The ID (:id in Express) is a unique identifier for that specific resource.

HTTP status codes are crucial for your API to communicate the outcome of a request to the client. They tell the client if the request was successful, if there was an error, and why.

• 200 OK: Request successful.
• 201 Created: Resource successfully created.
• 204 No Content: Request successful, but no content to return (e.g., DELETE).
• 400 Bad Request: Client sent invalid data.
• 404 Not Found: Resource not found.
• 500 Internal Server Error: Server-side error.

Let's design endpoints for a User resource. Notice how HTTP methods and URLs combine to describe actions.

Try running this example to see the routes in action:

Here's another example for a Product resource. The patterns remain consistent, making your API easy to understand and use for developers.

Run this code to see a product-focused API:

To ensure your API is user-friendly and maintainable, follow these best practices:

• Use Plural Nouns: For collections (e.g., /products, not /product).
• Avoid Verbs in URLs: Let HTTP methods define actions (e.g., POST /users, not /createUser).
• Use Hyphens: For readability in multi-word resource names (e.g., /order-items).
• Keep URLs Simple: Avoid deep nesting; query parameters can handle filtering/sorting.

Which of the following endpoint designs correctly follows RESTful principles for creating a new product and retrieving a specific product?

Great job! You've learned the fundamentals of designing RESTful API endpoints. Remember these key takeaways:

• Resources are the nouns, identified by URLs.
• HTTP Methods (GET, POST, PUT, DELETE) define actions.
• Use plural nouns for collections and specific IDs for items.
• Communicate outcomes using appropriate HTTP Status Codes.
• Strive for clean, predictable URLs for a user-friendly API.

This foundation will help you build robust and intuitive APIs!