REST API - filter of attributes in media type parameters

Question

I want to find some recommendations regarding the development of the REST / hipermedia API and, in particular, regarding the implementation with the django-rest framework.

Instead of the typical "entity" example, I will use the more mundane "document" object.

Question 1.

GET /document/?[query] 

gets a list of documents. The problem is that the “document” has several dozens of attributes, and in many cases the client will only care about a few (especially in this search) - the response size can vary as much as (up to 10) times, and server requests can be faster . In addition, I must mention that we prefer to be without a scheme.

I found samples for example

 GET /document/attr1, attr2../?[query] 

which I find pretty uncontrollable.

Another article suggested using Content-Types (actually Accept, as for queries), but the example was missing and still has a mixed feel. Sort of:

 Accept: application/json; attrs="attr1,attr2" 

I’m not sure if this refers to the semantics of HTTP, and also if such use of parameters such as multimedia is appropriate (because I want a different representation of the resource - with some attributes filtered out).

Question 2.

If the above is a more or less acceptable solution, I wonder if there is something ready in django-rest regarding the analysis of attributes of a custom media type. From what I see in the documents, the parameters of the media type are not separately processed (or processed).

Edit

Additional information: most of the application is OLTP (there will be no caching). The architecture is a JSON server with static files, a heavy JS client.

Edit 2

Actually, I found several opinions that the search by its nature is the creation of a new (mutable) resource (result), so the POST method is more suitable. This fixes the issue under discussion. I have some problems with the created entity (result), since I do not want to stop it, but I think this is not mandatory. The question is what to add the heading "Location" (dummy URL, no heading location or else)? The only consistent behavior for me is exactly what I don't want to do - the POST search does the search, saves the result on the server side and returns 201 with a link to it. This, however, is an unjustified constant load ...

Regarding browser testing, text / html of type MIME may present a searchable form.

Answer 1

Architectural styles describe architectures that limit designs that are then implemented. REST is an architectural style. It’s difficult for you to design URIs, not because implementation options are limited, but because of an architecture mismatch. Your customer "wants" to maximize efficiency by reducing the number of messages. But your chosen architectural style (REST) uses caching to increase efficiency , which, of course, leads to an increase in message volume (and, consequently, to fewer resources). If your architecture does not use caching for maximum efficiency, it deviates from the REST style (and perhaps creates a new style, Roy should do an architectural analysis of this very common style).

The solution is to either choose a different architectural style (RPC maximizes efficiency by reducing message size), or influence your client to get REST due to quality advantages , it provides: scalability, simplicity, efficiency, mutability and user experience performance.