RESTful API: Should I send URI parts in the response body? And how about Updating them? [closed]

问题

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"
    } ]
}

回答1:

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.

回答2:

You can use URI templates

if you want the user to fill in some parameters with input fields.
if you want to make your response smaller, but that is much easier with gzip

You should follow the HATEOAS principle: the clients should not break if you change the URI structure. So roughly the client should not build URIs, or if it builds URIs, then always the server gives the recipes how to do it, so if the recipes change, the client can adapt. This is very similar to how browsers work, they follow links given by the HTTP server...

回答3:

I am not sure i understand your question entirely. However, including URI's to objects in your response is a constraint of REST called HATEOAS. Have a look here: http://spring.io/understanding/HATEOAS

Response formats are not a concern of REST.

来源：https://stackoverflow.com/questions/25640069/restful-api-should-i-send-uri-parts-in-the-response-body-and-how-about-updatin

标签

rest

restful-architecture