Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate serializers for different endpoints #440

Closed
TehMillhouse opened this issue May 15, 2015 · 2 comments
Closed

Separate serializers for different endpoints #440

TehMillhouse opened this issue May 15, 2015 · 2 comments

Comments

@TehMillhouse
Copy link

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:

{
  "num_results": 2,
  "objects": [
    {
      "id": 1
    },
    {
      "id": 2
    }
  ],
  "page": 1,
  "total_pages": 1
}

While GET /api/orders/1 would return:

{
  "id": 1,
  "name": "Customer McBuy",
  "item_ids": [
    13,
    52,
    7
  ]
}

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 :)

@jfinkels
Copy link
Owner

jfinkels commented Feb 4, 2016

The code has been completely rewritten to support the JSON API protocol, so I'm not sure if this issue still applies. Related to #475 as well.

@jfinkels
Copy link
Owner

This should be fixed by pull request #493.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants