You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, serializers just flat out don't work for anything but vanilla GET requests (see #413, #422). A pattern seen relatively often in the wild for REST interfaces is to provide only a listing of objects for the GET_MANY endpoint and only serializing all fields of an object for the GET_SINGLE endpoint.
i.e., something like GET /api/orders would return:
It would be very nice to be able to do this with Flask-ReSTless without taking a huge performance hit, however the current custom serializer support is very limited. My proposition is:
introduce a new keyword parameter to create_api called serializers which works just like pre/postprocessors: a dict which specifies for every version of every endpoint which serializer is to be used. (optionally deprecate the current serializer argument (as it's broken) or use it as fallback for endpoints not specified in serializers)
This would take care of #413 and #422 and incidentally scratch my own itch :)
The text was updated successfully, but these errors were encountered:
Currently, serializers just flat out don't work for anything but vanilla
GET
requests (see #413, #422). A pattern seen relatively often in the wild for REST interfaces is to provide only a listing of objects for theGET_MANY
endpoint and only serializing all fields of an object for theGET_SINGLE
endpoint.i.e., something like
GET /api/orders
would return:While
GET /api/orders/1
would return:It would be very nice to be able to do this with Flask-ReSTless without taking a huge performance hit, however the current custom serializer support is very limited. My proposition is:
introduce a new keyword parameter to
create_api
calledserializers
which works just likepre
/postprocessors
: a dict which specifies for every version of every endpoint which serializer is to be used. (optionally deprecate the currentserializer
argument (as it's broken) or use it as fallback for endpoints not specified inserializers
)This would take care of #413 and #422 and incidentally scratch my own itch :)
The text was updated successfully, but these errors were encountered: