我正在构建RESTful API，我不确定在响应{{1}中发送与URI部分相同的信息是否存在问题（并且违反了REST）或不。
body GET调用会从数据库中获取此元素的数据，该数据库还包含/element/$ID以及element_ID的最后一部分。现在客户正在使用正文中的URI，但更改它们不会有问题，如果在element_ID 中不应该这样做。
在响应正文中发送RESTful API部分是否有问题？
（如果是这样，这些部件应该可以改变）
是否应从响应正文中删除数据，以便客户必须使用URI来提取所需信息？我看到的主要问题（由于冗余而导致不必要的开销）是客户希望更改与构建URI相关的字段（例如，在URI上使用PUT并更改{{1 }}
这是一个问题（/element/$ID也用于element_id）：
element_id如果您对此模型进行以下调用会发生什么
URI或者模型看起来应该更像这样？
{
"name": "Robert",
"element_id": 1337
"links": [ {
"rel": "self",
"href": "http://domain.tld:8080/element/1337"
} ]
}
答案 0 :(得分：3)
要遵循HATEOAS约束，客户端应使用服务器提供的URI来“动态地导航Rest接口”。
因此，如果您提供此＆＃34; element_id＆＃34;，则不违反HATEOAS约束，但您的客户端会违反，如果它使用它来构建他的URI服务器提供的使用地点。
为了不给客户提供这样的机会，最好考虑识别内部＆＃34;并且不要将其包含在文档中。但在某些情况下，您可以使用相关的元素信息（即＆＃34;用户名＆＃34;）来构建URI，您必须包含它。
重要的是客户端不应该尝试构造URI来访问API。
它的好处是允许重新组织或放大Rest接口而无需修改客户端，例如明天你可能想要在项目中对元素进行分组（比较一下）并希望将你的href更改为
＆＃34; http://domain.tld:8080/project/01/element/1337＆＃34;
如果您的客户遵循HATEOAS，则无需更改。
答案 1 :(得分：3)
您可以使用URI templates
您应该遵循HATEOAS原则：如果您更改URI结构，客户端不应该中断。所以粗略地说客户端不应该构建URI，或者如果它构建URI，那么服务器总是给出食谱如何做，所以如果配方改变，客户端可以适应。这与浏览器的工作方式非常相似，它们遵循HTTP服务器提供的链接......
答案 2 :(得分：1)
我不确定我完全理解你的问题。但是，在响应中包含对象的URI是REST的约束，称为HATEOAS。看看这里：http://spring.io/understanding/HATEOAS
响应格式不是REST的关注点。