Recommendation for versioning many=True endpoints

[phillbaker]

Thanks for your work on this library, it's been very useful!

We have a few version changes where, rather than changes the values within a response, are changing what's sent back with the response. For example, if an endpoint started returning Foo.objects.all(is_bar=True), we might update it to return Foo.objects.all().

To date, we've been taking the approach of returning different responses in the views, e.g.:

if request.META.get('HTTP_API_VERSION', CURRENT_VERSION) <= '0003':
    serializer = FooSerializer(foos, many=True, context={'request': request})
    return Response({'foos': serializer.data})

What would be the recommended approach for handling that with this library? (It doesn't look like it's currently handled.)

[mrhwick]

This is a pretty interesting use case. I had limited this library to handling only changes in the actual representations of resources being serialized back for clients. I think an extension of this library that provides some notion of endpoint middlewares that act as both transforms and endpoint boilerplate for common use cases like this might be an interesting addition.

Although it is outside of the current scope of this library, I can see why it would be useful for some kinds of versioning.

Maybe this is an approach you could try for your use case. You have a new version of your endpoint that begins returning a more specific set of data. That means the old version wants a superset of the data returned in the newer versions. Introduce a field in a transform forwards method which is used for filtering the response data in some way and only intended for internal use. You could discard any value coming from the actual request to be safe. You would want to have that field populated by a sentinel value indicating you don't want to do that filtering in the endpoint if that field has this sentinel value. Then your endpoint code would use that to fetch the superset of objects that was once returned.

In your endpoint code, you would then check for that field and filter or not filter as needed. I have an idea of how I would implement this use in actual sample code so I could write that if it is helpful to you. Ideally, the library could provide this as a new feature for certain kinds of views that are expected to be used this way.