Specifying projection for a REST GET query

Question

Does specifying projection for a REST GET query violate REST principle and/or is it a good practice ??
Consider an api like /person?fields=fname,lname, address , this might be because person is a big model and for my current requirement i only require value of the given fields( say I am creating a UI grid)

Answer 1

It's completely okay to define a new resource if the current ones does not support what you want. That's exactly how REST works.

So in your case the /person?fields=fname,lname, address URI definition is perfectly valid.

Note that the URI structure does not matter, you have to provide links to the clients in where you describe the URI template and the variables. So you should return a link something like this (fictional hypermedia JSON format):

{
    "_links": {
        "/meta/person/list": {
            "href": "/person{?fields}",
            "vars": {
                "fields": {
                    "required": false,
                    "composition": [
                        "fname": {
                            "meta": "/meta/person/fname"
                        },
                        "lname": {
                            "meta": "/meta/person/lname"
                        },
                        "address": {
                            "meta": "/meta/person/address",
                            "alternatives": {
                                "href": "/locations",
                                "meta": "/meta/locations"
                            }
                        }
                    ]
                }
            }
        }
    }
}

In where the /meta describes the type and label of each params:

GET /meta/person/fname

{
    "type": "string",
    "label": "First name",
    "_links": {
        "self": {
            "href": "/meta/person/fname"
        }
    }
}

Ofc. your first move with the client should be getting the whole meta or at least the most frequently used parts of it. By processing the link, the client must be able to understand the meta description and this special hypermedia JSON format only. The URI structure is completely irrelevant, it should use only the meta to understand what the link is, and how to use it.

Unfortunately we don't have a standard at the current time about how to describe links in the JSON response. There are hypermedia formats like Hydra+Json-LD, HAL, HyperSchema, etc... But afaik. none of them is a standard yet. (Probably the Hydra RDF vocab is the closest to become one, but it is surely not production ready yet. Json-LD already is a standard way to represent RDF.)

Now if it is hardcoded into your client how to build the /person?fields=fname,lname,address URI and what it means, then it is not a REST client, because this kind of services/clients violate the uniform interface / HATEOAS constraint of REST. Ofc. nowadays ppl. call everything as REST, RESTful, API, even when they know only as much as Jon Snow about the topic. Btw. there is no tragedy if you don't want to implement your web application in a REST way, it only depends on your requirements. For example if your application won't have a lot of users and 3rd party developers it most likely won't matter which path you choose.