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

```

Answer: 
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.
You can use [URI templates](https://www.rfc-editor.org/rfc/rfc6570)

* 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...