一个资源 URI 应当读起来像一条通往某个“东西”的、基于名词的 path，而不是一个动作。HTTP method 已经提供了动词，所以 URI 只需清晰、一致地标识资源。
一个资源 URI 应当读起来像一条通往某个“东西”的、基于名词的 path，而不是一个动作。HTTP method 已经提供了动词，所以 URI 只需清晰、一致地标识资源。
GET /users/42——而不是 GET /getUser?id=42。method（GET）才是动词。/users 是 collection；/users/42 是其中一个成员。处处保持复数使其可预测。/users/42/orders = “属于 user 42 的 orders”。kebab-case、小写。 /blog-posts，而不是 /blogPosts 或 /Blog_Posts。/users?role=admin&sort=-created_at。/users collection of users
/users/42 a single user
/users/42/orders orders belonging to user 42 (sub-collection)
/users/42/orders/1001 a specific order of that user
/orders/1001 same order, addressable at top level too
GET /users/42/orders?status=shipped&sort=-created_at&page=2 HTTP/1.1
Accept: application/json
避免超过一两层的深度嵌套——/users/42/orders/1001/items/5/reviews 会变得脆弱。一旦 order 有了自己的 ID，就优先用 /orders/1001。对于不适合 CRUD 的动作（例如“发送邮件”），一个 controller 风格的 sub-resource 是可以接受的：POST /users/42/verify-email。
一致的命名是让一个 API 感觉直观的原因——一个见过 /users 和 /users/42 的开发者，无需读文档就能正确地猜出 /products 和 /products/99。面试官用它来衡量你是否用资源（REST 思维）而不是 RPC 调用（/doThisThing）来思考。最常见的反模式——path 中的动词、不一致的复数化、以及深度嵌套的 URL——都会让 API 更难学习和维护，并表明一个尚未内化 REST 的 uniform-interface 约束的开发者。好的 URI 设计还能保持关注点分离：身份在 path 中、过滤和分页在 query string 中，这让缓存和路由保持整洁。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠