RESTful API:我应该在响应正文中发送 URI 部分吗?更新它们怎么样? [英] RESTful API: Should I send URI parts in the response body? And how about Updating them?

问题描述

我正在构建一个 RESTful API，但我不确定发送与 URI 部分相同的信息是否有问题(和违反 REST)响应 body 与否.

现状

GET /element/$ID 调用从数据库中获取此元素的数据，该数据库还包含 element_ID 和URI 的最后一部分.现在，客户端正在使用主体中的 element_ID，但是更改它们不会有问题，如果它不应该在 RESTful API 中使用这种方式.

一般问题

在响应正文中发送 URI 部分是否有问题?
(如果是这样，这些部分应该是可变的)
是否应该从响应正文中删除数据，以便客户端必须使用 URI 来提取所需的信息?我看到的主要问题(除了由于冗余导致不必要的开销)是当客户端想要更改与构建 URI 相关的字段时(例如在 /element 上使用 PUT/$ID 并更改 element_id 字段).

示例

这会不会有问题(element_id 也用于 URI):

<代码>{"name": "罗伯特",element_id":1337链接":[ {"rel": "自我","href": "http://domain.tld:8080/element/1337"]]}

如果你对这个模型进行以下调用会发生什么

PUT http://domain.tld:8080/element/1337{"name": "罗伯特",element_id":1234}

或者模型应该看起来更像这样吗?

<代码>{"name": "罗伯特",链接":[ {"rel": "自我","href": "http://domain.tld:8080/element/1337"]]}

解决方案

为了遵循 HATEOAS 约束，客户端应该使用服务器提供的 URI 来动态导航 Rest 接口".

因此，如果您提供此element_id"，则不会违反 HATEOAS 约束，但是您的客户端将违反它，如果它使用它来构建他的 URI 来代替服务器提供的使用.

为了不给客户这种机会，最好将该标识视为内部"标识，并且不要将其包含在文档中.但在某些情况下，您可以使用相关元素信息(即用户名")来构建 URI，并且必须包含该信息.

重要的一点是客户端不应该尝试构造 URI 来访问 API.

它的好处是允许在不需要修改客户端的情况下重组或放大 Rest 接口，例如明天你可能想要对项目中的元素进行分组(说点什么)并且想要将你的 href 更改为

"http://domain.tld:8080/project/01/element/1337"

如果您的客户关注 HATEOAS，则无需更改.

I am building a RESTful API and I am not sure whether it is a problem (and violation of REST) to send information that is the same as URI parts in the response body or not.

Current Situation

An GET /element/$ID call gets you data of this element from the database, which also contains the element_ID and with that the last part of the URI. Right now clients are using element_ID from the body, but changing them would be no problem, if it should not be this way in a RESTful API.

General Question

Is it a problem to send URI parts in the response body?
(and if so should these parts be changeable)
Should the data be removed from the response body so clients have to use the URI to extract needed information? The main problem (additional to unnecessary overhead because of redundancy) I see is when clients want to change fields relevant for building the URI (e.g. use PUT on /element/$ID and change the element_id field).

Examples

Would this be a problem (the element_id is also used for the URI):

{
    "name": "Robert",
    "element_id": 1337
    "links": [ {
        "rel": "self",
        "href": "http://domain.tld:8080/element/1337"
    } ]
}

And what would happen if you make following call on this model

PUT http://domain.tld:8080/element/1337
{
    "name": "Robert",
    "element_id": 1234
}

Or should the model just look more like this?

{
    "name": "Robert",
    "links": [ {
        "rel": "self",
        "href": "http://domain.tld:8080/element/1337"
    } ]
}

解决方案

To follow the HATEOAS constraint, clients should use URI's provided by the server to "dinamically navigate Rest interfaces".

So, if you provide this "element_id", you not violate HATEOAS constraint, but your client will violate it if it uses that to construct his URI's in place of use that provided by the server.

To don't give that chance to clients it will be better to consider that identification an "internal" and don't include it in the document. But in some cases you could use relevant element information (i.e. "user name") to construct the URI and you must include that.

The important point is that the client should not try to construct the URIs, to access the API.

The benefit of it is to allow reorganization or amplification of the Rest interface without the need to modify the client, for example tomorrow you could want to group elements in projects (to say something) and want to change your href to

"http://domain.tld:8080/project/01/element/1337"

if your client followed HATEOAS it will need no changes.

这篇关于RESTful API:我应该在响应正文中发送 URI 部分吗?更新它们怎么样?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！