他们在这个网站以及可能在任何其他网站上都这样做,但我不确定我理解为什么。
一个流行的类比将 RESTful 资源与文件系统中的文件进行比较,文件名静态网页相同的对象,并且在静态网站中users
不会指向与文件名users/
users
会指向users.html
和users/
- 指向不同的文件 - users/index.html
。
filename
users
不会指向与 filename 相同的对象users/
。
那不是真的。在大多数文件系统中,您不能在同一个父目录中拥有一个命名的文件users
和一个命名的目录。users
cd users
并cd users/
得到相同的结果。
简短的回答:如果一个重定向到另一个,他们可能只会识别相同的资源。
URI 标识资源,但根据对HTTP 中 GET 请求的响应状态代码,它们会有所不同。如果一个向另一个返回 3xx,则这两个 URI 标识相同的资源。如果这两个资源各自返回一个 2xx 代码,则 URI 标识不同的资源。它们可能会返回相同的响应以响应 GET 请求,但因此它们不是相同的资源。这两个资源甚至可以映射到同一个处理程序以产生它们的回复,但它们因此不是同一个资源。引用罗伊菲尔丁的话:
资源不是存储对象。资源不是服务器用来处理存储对象的机制。资源是一个概念映射——服务器接收标识符(标识映射)并将其应用于其当前映射实现(通常是特定于集合的深度树遍历和/或哈希表的组合)以找到当前负责的处理程序实现和处理程序实现然后根据请求内容选择适当的动作+响应。
/users
那么,应该/users/
返回相同的响应吗?不,如果一个没有重定向到另一个,那么他们应该返回不同的响应。但是,这本身并不是 REST 的约束。然而,这是一个约束,它使网络系统更具可扩展性:在多个资源中重复的信息可能会不同步(尤其是在存在缓存的情况下,这是REST 的约束)并导致竞争条件。完整的讨论请参见 Pat Helland 的Apostate's Opinion。
最后,客户端在尝试解析与给定 URI 相关的引用时可能会中断。URI 规范清楚地表明,Jerry/age
解析相对引用会/users/
导致. 令人惊讶的是,已经编写了多少客户端代码来检测和纠正后者以使其表现得像前者(但并不总是成功)。/users/Jerry/age
/users
/Jerry/age
对于任何集合(/users/
通常是),我发现最好始终在 URI 中发出,每次都/users/
重定向/users
到,并提供来自资源的最终响应:这可以防止实体不同步并使相对分辨率在任何客户端上都很容易./users/
/users/
这有一些细微差别,而“用户”代表一个资源,而“用户/”应该代表一组资源,或者对所有资源“用户”的操作......但似乎不存在一个“标准”问题。
对此还有另一个讨论,请看这里:https ://softwareengineering.stackexchange.com/questions/186959/trailing-slash-in-restful-api
从技术上讲,它们并不相同。但是请求/users
可能会导致重定向,/users/
从而使它们在语义上相等。
就 JAX-RS 而言@Path
,它们都可以用于同一路径。