Question

如果实体（例如人）拥有必须以不同表示形式呈现的数据：

我有一个很大的个人资料，但有一个小例子：

representations1：

GET /profiles/{id}/activity/projection1

返回：

{"actions":["add", "delete", "add"], "dates":[1499865456, 1499861544, 1499863655]}

representations2：

GET /profiles/{id}/activity/projection2

返回：

{add_at:[1499865456, 1499863655], delete_at:[1499861544]}

所以问题是：如何设计这样的案例？我有一些想法，但不知道哪一个更好

GET /profiles/{id}/activity/projection1
GET /profiles/{id}/activity/projections/1
GET /profiles/{id}/activities/projection1
GET /profiles/{id}/activities/projections/1
GET /profiles/{id}/activity-actions and GET /profiles/{id}/activity-timestamps

我发现只有一个相同的问题Different RESTful representations of the same resource但它是关于过滤数据而不是关于变更模型

Answer 1

要牢记几件事

就REST而言，具有不同标识符（URI）的两件事是不同的资源。事实上，他们拥有相同的事实来源是一个实施细节。

在设计REST api时，您的资源是集成点。资源的表示将取决于模型在任何给定时间的状态。

例如，如果我在棒球参考中查找Clayton Kershaw，我可能会被引导到这个资源

http://www.baseball-reference.com/players/k/kershcl01.shtml

但如果我要求看到他的“2014拆分”，那么我将转而使用此资源。

http://www.baseball-reference.com/players/split.fcgi?id=kershcl01&year=2014&t=p

与kershcl01相关的每个资源标识符都必须位于层次结构中的同一个根目录下。

您可能想要查看Cool URIs don't change;随着时间的推移，稳定的URI是设计的一个很好的目标，在这种情况下，您需要确保临时实现细节不会泄漏到URI空间中。

Jim Webber的观察是REST资源是集成域的一部分; “资源使您的网络模型适应网络。”

因此，您的设计指南应该来自于询问哪些属性对您的消费者很重要，以及哪些约束将确保这些属性存在（外部），而不是从您的（当前）实现开始。

休息：同一资源的不同表示

1 个答案: