我的JSON响应应该包含请求查询参数的值吗？

假设我有一个端点返回人名。我允许我的客户按国家筛选结果。

我想知道，我是否应该在回应中包含country属性，即使它与客户请求的内容相匹配。

例如，当用户发送下面的请求

/人？国家=英国

，我应该回到

[{"name":"tom"},{"name"="tim"}]

或

[{"name":"tom","country":"UK"},{"name":"tim","country":"UK"}]

的反应呢？

来源

2016-10-18 rawData

我认为它会归结为约定可能对于某些JSON结束点在你的应用程序您需要在响应中描述用户所做请求的节点。也许别人不会。 – mmcrae

我会让客户决定要查看哪些信息。因此内容谈判是关键的术语。通过使用像'people'这样的资源并返回预定义的内容，您基本上可以将客户端紧紧绑定到[typed resource]（http://soabits.blogspot.co.at/2012/04/restful-resources-are- not-typed.html），这与您尝试从服务器中解除客户端的实际REST原理相违背。 –

取决于客户需要的数据。

如果你只是想告诉客户他们要求什么，你可以在你的API中有一些约定，那就是有一个顶层节点来显示请求中的参数是什么产生了这个响应。

{"requestParams":"country=UK&city=London", data: [{"name":"tom", "street":"Wallaby"}, {"name":"tim", "street":"West"}]

但你肯定不希望冒险通过返回的请求参数返回敏感信息。

来源

2016-10-18 14:09:49 mmcrae

为了回答您的问题，我们首先应该澄清REST背后的实际意图，因为这经常被误解。 REST不是关于干净的URIs或类似API的流行词，而是关于将客户端与服务器分离的类似于Web浏览器的服务器更改相当健壮并且几乎不中断的服务器。

为了实现这一目标，客户端不应该对API或其资源有任何假设或预定义的知识。它需要知道的一切应该通过请求 - 响应交互来学习。这并不容易实现，但可以确保在服务器端进行的更改不会中断。

因此，服务器应该包含客户端可以用来在调用这些URI时执行状态更改的链接（HATEOAS）。支持协议（通常是HTTP）定义了您可以在这些URI上执行的动词（或方法）。为了避免客户端连接到服务器，客户端可以发送一个已知的支持文档格式列表（例如在网络浏览器中的text/html）到服务器，服务器可以选择一种支持的文档类型并将该格式的资源（如果支持）。这种内容类型现在定义了返回给客户端的内容。这可能是刚刚转换为相应表示的资源的完整内容（因此表示状态转移; REST），或者可能只是某些资源状态的子视图。

已有多种可用的内容类型定义，但API提供程序可以创建自己的内容类型定义，或者根据需要从其他类型定义扩展。但是，自定义内容类型的缺点是客户需要以某种方式学习这些内容类型。媒体类型虽然是RESTful客户端的实际知识库，Roy Fielding也表示大部分设计工作应该被放入媒体类型及其处理中：

REST API应该花费几乎所有的描述性工作定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体类型定义扩展关系名称和/或启用超文本的标记。用于描述在感兴趣的URI上使用什么方法的任何努力应该在媒体类型的处理规则的范围内（并且在大多数情况下已经由现有媒体类型定义）完全定义。 [在这里失败意味着外的频带信息交互推动，而不是超文本。（Roy Fielding）

虽然application/xml和application/json是很受欢迎并得到广泛支持，他们不传达很多语义。类似application/atom+xml或application/hal+json至少支持链接以支持HATEOAS的要求。

所以，为了真正的REST风格，你应该重新使用要么喜欢vCard现有的内容类型，请people信息或设计新的东西，并予以公布，以便客户端实现者有一种方式来学习处理这些内容类型。常见的vcard内容类型已经定义了您在自定义内容类型时可能返回的内容，您可以随意返回任何您想要的内容，但至少支持此内容类型的客户端将能够进一步处理数据。

来源

2016-10-18 14:58:58

我不认为他实际上在谈论重新调整人，这只是一个简单的例子。虽然另一个关于REST的教育永远不会受到伤害，但他的实际问题与REST无关。 –

@NicholasShanks当我创建答案的时候，OP在标题中包含了'REST'项，并且还有'rest'标签，你可以在修订版后看到它。虽然我同意，但我的答案可能没有完全回答OP的问题或样本，尽管我已经在评论中给OP提示了一些提示。我会考虑在我的回答中加入这个评论。 –

是的，我看到了，是我编辑它的。你写的很棒;它只是没有回答被问到的（错误标记的）问题:-) –

我只是说你应该选择一个最小代表您的项目发送与收集回应，并保持一致，在返回这些。

由于查询值始终取决于最终返回的项目的基础数据，因此该数据属于您在请求单个项目时返回的表示形式 - 即/ people/tom会包括{“country：”UK“}。简单地决定要包含在列表中的完整项目的哪些部分。

如果提供的查询过滤器属性不是通常的最小表示形式”个人“，那么就不要包含它，如果它通常是你在/ people？foo调用中包含的人员数据的一部分，那么它仍然包含它

来源

2017-01-02 19:28:12

我的JSON响应应该包含请求查询参数的值吗？

回答

相关问题