wimglenn / djangorestframework-queryfields

Allows clients to control which fields will be sent in the API response

Django REST framework QueryFields

Allows clients to control which fields will be sent in the API response. Fields are specified in the query, e.g.

# You want a list of users but you're only interested in the fields "id" and "username":

GET /users/?fields=id,username

[
  {
    "id": 1,
    "username": "tom"
  },
  {
    "id": 2,
    "username": "wim"
  }
]


# You want to see every field except "id" for the specific user wim:

GET /users/2/?fields!=id

{
  "username": "wim",
  "email": "[email protected]",
  "spirit_animal": "raccoon"
}

Supported Django versions: 1.7 - 3.2+. Check the CI matrix for details.

Documentation is hosted on Read The Docs.

Developers, developers, developers!

Want to contribute to the project? This is how to run the test suite:

# get the codez
git clone https://github.com/wimglenn/djangorestframework-queryfields.git

# create and/or activate your virtualenv, this or something like it:
cd djangorestframework-queryfields
python3 -m venv .venv
source .venv/bin/activate

# installing the app in your venv
pip install --editable ".[dev]"
git checkout -b myfeature

# hack away, then ...
pytest

djangorestframework-queryfields's Issues

Consider overriding to_representation instead of modifying self.fields

Hey Wim, nice little useful package this one, I was surprised they don't support this out of the box.

One thing I'd consider is having your mixin override to_representation (http://www.django-rest-framework.org/api-guide/serializers/#baseserializer) instead of manually popping the fields out of the serialiser instance. to_representation already returns a dict, so you could call super(), access self.context['request'] to determine the fields to exclude, and finally use pop on the dict returned from super.

To me this way has these two advantages:

• It feels a bit "cleaner" to me as overriding to_representation seems the recommended way to customise serialisation behaviour without affecting the serialiser in other contexts (e.g. input).
• Popping the fields is "destructive" in the sense you wouldn't be able to reuse the same serialiser instance with the default behaviour. Inside to_representation you can access self.context and decide what to exclude from the output.

Cheers!

Actually avoid hitting the DB

I don't know if this is at all possible, but it'd be great if a fields request was actually more efficient due to not hitting the DB for a given field. We have some rather large fields, and while it's great not to have to serialize them, pulling them from the DB is a big job too. If we could avoid that too, it'd be huge.

Options are read from settings

It would be a nice feature, if we could define include_arg_name, exclude_arg_name and delimiter in settings.py.

I'm gonna write PR if I find the time.

Add Django 2.2 to CI matrix

• change base_name to basename in tests router
• use "3.7-dev" instead of xenial dist

Documentation on test is missing

dev requirements:

pip install mock_django

manage.py:

#!/usr/bin/env python
import os
import sys

if __name__ == "__main__":
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "test_settings")

    from django.core.management import execute_from_command_line

    execute_from_command_line(sys.argv)

Omit expensive field by default

I have a field that I want to exclude by default and only include when requested. This is currently not possible (AFAICT).

Any insight on how I could implement this in a PR?

Thanks.

QueryFieldsMixin and GeoFeatureModelSerializer

I'm trying to use QueryFieldsMixin, along with GeoFeatureModelSerializer from django-rest-framework-gis as follows:

class gauge_station_source_data_Serializer(QueryFieldsMixin, GeoFeatureModelSerializer):

However, when I specify ?fields=field1,field2 in my url, it still returns all the fields available, instead of just field1 and field2.

I can use QueryFieldsMixin without GeoFeatureModelSerializer, on a none geospatial model, and it works fine.

Jim

Select fields in POST/PATCH requests

I have an APIView with get, post, and patch methods. and I am returning data through a QueryFieldsMixin-inherited serializer, passing the request as context, like this:

[GET] return Response(ThingSerializer(analyses, many=True, context={'request': request}).data)
[POST] return Response(AnalysisSerializer(analysis, context={'request': request}).data, status=status.HTTP_201_CREATED)
[PATCH] return Response(AnalysisSerializer(analysis, context={'request': request}).data)

However, the fields= and fields!= only work with the GET requests. In the other cases, the full object, which has a very heavy field that I must not return, is returned. Is this expected behavior?

getting particular nested fields not working using this fields filtering

My GET body is like below:
GET : /images

 {
        "id": 1,
        "images": [
            {
                "image": "e3942bf0-6c6.png",
                "width": 353,
                "height": 200,
                "size": 168306,
                "aspect_ratio": 1.765,
                "rendition": null
            }
         ]
}

I want to filter only width and height fields i.e.,
GET:/images?fields=width,height

Expected result:

 {
                "width": 353,
                "height": 200
}

But i am unable to specify nested fields while filtering fields
How can I acheive this??

Add note to docs / github landing to mention supported Django/DRF/Python versions

hi there:

sorry for such a trivial question, but does drf queryfields support DRF 3.x yet? I don't see any explicit mention of which versions you do or don't support in your docs. we're in the middle of migrating from DRF 2.x to 3.0.0 and were getting some exceptions, but it's not super clear yet if the problem is with our code (probable) or whether you just don't support 3.x yet. Again, sorry for such a simple question.

The fields parameter doesn't appear in API docs

The fields and fields! parameters don't appear in DRF's autogenerated api docs. It'd be nice to have code and/or docs on how to add these parameters in djangorestframework-queryfields.

"values_list" equivalent with flat=True functionality

I watched a consumer of an API using this iterate over and over on a list of dicts for 1 field. In the Django ORM, this is where something like foo_queryset.values_list('name', flat=True) would be a no brainer to make it easier to use the results.

Based on the conversation I've already had with @wimglenn this seems to be the blessed approach:

1. fields_list instead of fields will return an array of arrays (list of lists) since this is JSON we're talking about
2. fields_list queries can have an optional flat query argument which will flatten the array of arrays into a single array containing the results akin to flat=True will when calling a queryset with values_list()
3. Due to keys being inherently unordered, fields_list!=foo,bar,baz will not be supported as there is no way to predetermine the field ordering.
4. Any request using multiple fields along with flat should return a HTTP 400 Bad Request e.g: fields_list=foo,bar&flat is invalid.

So given data from this request:

GET /api/animals/?fields=name,type

{
    count: 2,
    next: null,
    previous: null,
    results: [
        {
            name: "wombat",
            type: "marsupial"
        },
        {
            name: "wallaby",
            type: "marsupial"
        }
    ]
}

A query such as:

GET /api/animals/?fields_list=name,type

Would return data such as:

{
    count: 2,
    next: null,
    previous: null,
    results: [
        ["wombat", "marsupial"],
        ["wallaby", "marsupial"]
    ]
}

GET /api/animals/?fields_list=name&flat or GET /api/animals/?fields_list=name&flat=true

Would return data such as:

{
    count: 2,
    next: null,
    previous: null,
    results: [
        [
            "wombat",
            "wallaby"
        ],
    ]
}

Feature already implemented in DRF ^3.4.0?

What's different in this lib?

Default fields and required fields

We could use default_fileds_name set to define the default return fields and use required_fields_name set to define the fields should be return whether they were include in the fields of query_params. Is it right? I would like to give a PR if we all agree with that.

Add Django 1.11 support

self.context is getting cleared in serializers.SerializerMethodField()

First please accept my gratitude for this awesome util.

If I derive my serializer from this mixin and if my serializer have a field which is a serializer.SerializerMethodField.

In that method we have been using self.context['request']; which stays available if I donot derive my serializer from QueryFieldMixin by it disappears if I do.

Any guidance will be appreciated

New Feature - Nested Fields

Hi, Thank you for the lib.
Would it be possible to add a mechanism for nested fields?
i.e. some how :
Given
GET http://127.0.0.1:8000/things/

[
  {
    "id": 1,
    "key1": "val1",
    "key2": "val2",
    "key3":{
      "id": 2,
      "key1": "valA",
      "key2": "valB",
      "key3": "valC",
    },
  }
]

then we could do :

GET http://127.0.0.1:8000/things/?fields=id,key3__id, key3__key2

[
  {
    "id": 1,
    "key3":{
      "id": 2,
      "key2": "valB"
    },
  }
]