作为服务器REST API设计的一部分，我正在考虑我希望能够返回以客户端授权级别为条件的数据。在完成该操作并仍将其称为一个API时，推荐的方法是什么？更具体地说，请考虑以下图书访问API的示例：
HTTP GET /library/books/{book-name}
任何经过身份验证的客户端都应该能够获取该书的（JSON）数据，例如：
{“ book”：{“ book-name”：“ abc”，“ author”：“ someone”}}
但是，经过身份验证的客户端的特定子集也应该能够获得：
{“ book”：{“ book-name”：“ abc”，“ author”：“ someone”}，“ private-info”：{“ book-status”：“ on-loan”，“ price”：“ $ 20 “}}
对于给定的书籍，任何经过适当授权的客户端也可以通过直接的HTTP GET / library / books / {book-name} / private-info访问“私人信息”。
现在，假设有合适的客户端身份验证方案，我不禁会认为上面的HTTP GET / library / books / {book-name}实际上看起来像两个API，通过服务器上有关身份验证的授权状态来区分。这似乎不是很好的RESTful。
也许最好使基本的GET book API都相同，而不需要任何“私有信息”，而仅向授权客户提供对私有信息URI的访问权，并将403返回给所有其他人？
REST API通常如何处理这种类型的条件数据访问？
您的方法没有内在的错误-根据用户的建议隐藏信息是很有意义的。REST对此无能为力-资源的表示形式可能取决于用户授权，月相或其他任何您能想到的东西。
但是，如果将私有信息提取到单独的资源中，则可以改善缓存。在这种情况下，/ library / books / {book-name}会有一些相当静态的内容，可以在客户端缓存。这样一来，您将拥有/ library / books / {book-name} / private-info信息，该信息会更加不稳定且依赖于用户-因此不容易实现。
在此基础上，您可以在原始资源中包括指向私人信息的链接：
{
Title: "A book",
Author: "...",
PrivateInfoLink: "http://your-api.com/library/books/{book-name}/private-info"
}
这样的好处有两个：
1）如果客户端无法访问私有信息，则服务器可以忽略链接，从而避免客户端不必要地往返（不）获取私有信息。
2）如果以后需要，服务器可以自由更改专用信息URL（例如，根据用户授权，它可以是不同的URL）。
如果您想了解更多有关超媒体的好处，请尝试以下方法：http : //soabits.blogspot.dk/2013/12/selling-benefits-of-hypermedia.html
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句