What are the best practices to add metadata to a RESTful JSON response?

Question

You have several means to pass metadata in a RESTful API:

1. Http Status Code
2. Headers
3. Response Body

For the metadata.status, use the Http Status Code, that's what's for! If metadata is refers to the whole response you could add it as header fields. If metadata refers only to part of the response, you will have to embed the metadata as part of the object.DON'T wrap the whole response in an artifical envelope and split the wrapper in data and metadata.

And finally, be consistent across your API with the choices you make.

A good example is a GET on a whole collection with pagination. GET /items You could return the collection size, and current page in custom headers. And pagination links in standard Link Header:

Link: <https://api.mydomain.com/v1/items?limit=25&offset=25>; rel=next

The problem with this approach is when you need to add metadata referencing specific elements in the response. In that case just embed it in the object itself. And to have a consistent approach...add always all metadata to response. So coming back to the GET /items, imagine that each item has created and updated metadata:

{
  items:[
    {
      "id":"w67e87898dnkwu4752igd",
      "message" : "some content",
      "_created": "2014-02-14T10:07:39.574Z",
      "_updated": "2014-02-14T10:07:39.574Z"
    },
    ......
    {
      "id":"asjdfiu3748hiuqdh",
      "message" : "some other content",
      "_created": "2014-02-14T10:07:39.574Z",
      "_updated": "2014-02-14T10:07:39.574Z"
    }
  ],
  "_total" :133,
  "_links" :[
     {
        "next" :{
           href : "https://api.mydomain.com/v1/items?limit=25&offset=25"
         } 
   ]
}

Note that a collection response is an special case. If you add metadata to a collection, the collection can no longer be returned as an array, it must be an object with an array in it. Why an object? because you want to add some metadata attributes.

Compare with the metadata in the individual items. Nothing close to wrapping the entity. You just add some attributes to the resource.

One convention is to differentiate control or metadata fields. You could prefix those fields with an underscore.

Along the lines of @Charlie's comment: for the pagination part of your question you still need to bake the metadata into the response somhow, but the status and message attributes here are somewhat redundant, since they are already covered by the HTTP protocol itself (status 200 - model found, 404 - model not found, 403 - insufficient privs, you get the idea) (see spec). Even if your server returns an error condition you can still send the message part as the response body. These two fields will cover quite much of your metadata needs.

Personally, I have tended towards (ab)using custom HTTP headers for smaller pieces of metadata (with an X- prefix), but I guess the limit where that gets unpractical is pretty low.

I've expanded a bit about this in a question with a smaller scope, but I think the points are still valid for this question.

I suggest you to read this page https://www.odata.org/ You are not forced to use OData but the way they do the work is a good example of good practice with REST.