URL中没有ID的RESTful API

资源标识是一个关键的REST约束.您的订单和我的订单不是相同的资源,因此他们应该(不必)具有不同的标识符.

你应该给他们一个唯一标识符(即/ customers/1234/orders)的实际原因是因为支持HTTP缓存会容易得多.HTTP缓存中介主要使用URI作为缓存键.通过使用vary头可以使用其他头(例如auth)作为缓存密钥的一部分,但是,对这种机制的支持不太可靠/普遍.

即使今天您没有计划使用HTTP缓存,最好还是安全地玩,并确保您的URI设计为在将来需要时允许此功能.

在进行客户端URI构建时,不必在URI中包含客户ID有一些好处.但是,RESTful系统应该通过在返回的表示中嵌入这些URI来为客户端提供URI.客户端不需要构建这些URI,因此客户端使用带有id的URI作为使用不带Id的URI的ZERO额外工作.如果您准备吞下超媒体药丸,那么不包括ID就没有优势.

我认为只有在您允许客户检索其他客户的订单数据时才需要第二个实施(包括客户ID).换句话说,如果客户4321将能够看到客户1234的订单历史记录,则发送该订单历史记录是绝对必要的.

我的猜测是他们无法做到这一点.这意味着如果您包含该信息,您可能会忽略它而无论如何都支持授权代码.

如果是这样,我说甚至不发送它.

如果它让你感觉更好,那么LinkedIn的REST API就会反映出这种行为.任何用户都可以请求任何其他用户的配置文件但如果省略ID它假定当前用户请求自己的个人资料. 在这里阅读更多

所有这一切,只要它对你有意义并且你记录它你就应该没问题.

两个人都不是RESTful.URI的语义应该与RESTful应用程序中的客户端无关.

REST是一种基于Web本身的架构风格.想一想.当你转到Stack Overflow时,你唯一关心的URI是stackoverflow.com.登录后,您将被重定向到主页,并且主页的URI无关紧要.现在我在我的菜单栏上有一个链接到我的主页,你有一个相同的链接进入你的主页,我们点击它时我们不关心URI是什么,对吧？在我们的主页上,我们看到问题和答案,我们也不关心他们的URI,只关注他们的标题和描述.

现在,让我们改变它.REST是网络的架构风格,如果网络就像你认为REST一样,当你加入时,你stackoverflow.com没有一个指向你主页的名字很好的链接你会有一个文字说"你的id是131809 ,请,使用URI模式/ users /(id),用这个数字替换id,将其粘贴到地址栏中,然后你将进入你的主页",你想,"为什么这些白痴不会建立链接为了那个原因？"

这听起来很荒谬,但这就是大多数人认为REST的含义.REST API必须是超文本驱动的.

这意味着,如果用户的订单应该是/customer/(customer_id)/orders,或者只是/customer/orders或者甚至/orders依赖于他的凭证,迫使客户端知道所有这些URI模式,而不是担心,您应该只在他的API入口点给他一个根文档,考虑他的凭据,并为URI提供标准的标题和描述,就像任何网站登录时一样!

所以,假设您使用JSON,而您的API就是myapi.com.这应该是客户端知道的唯一URI.当他GET使用适当的Authorization标头向该根文档发出请求时,他应该获得一个JSON文档,如:

{"orders": "http://myapi.com/customer/123456/orders"}

显然,他不需要知道"订单"的价值是什么,只是它是一个有效的URI,将导致他到另一个包含他的订单集合的资源.URI可以是任何东西,它的语义无关紧要.这可能是你朋友的建议:

{"orders": "http://myapi.com/orders"}

或其他任何可以随时更改的内容:

{"orders": "http://myapi.com/this/is/a/meaningless/uri"}

当然,您应该付出一些努力来获得清晰且有意义的URI,但这并不会使您的API或多或少具有REST.在这个问题上,使您的API RESTful是您的客户获取URI的方式,如果您的客户正在阅读文档中的URI模式而不是将其作为其他资源中的链接,那么您的API就不是RESTful.就那么简单.