Custom and simple response format?

[leplatrem]

@n1k0 suggested that we serve a custom and ultra simple response format for the ES results - instead of those vertiginous depths of json.

We could support a specific Accept: content-type and format what ES returns to serve a custom format.

But how can we cover the whole set of ES features? Is there just filtering and aggregations to cover?

What do you think?

I'm not super enthusiast about and probably not enough yet to put some efforts into it. But maybe somebody does?

[n1k0]

We're facing a classic. We're making a plugin for a vertiginously powerful external dependency (ES) and we'd love it to be generic, though we have a tiny business use case covering three or four key features of it.

Scenarios:

• We keep it highly native, so a lot of effort is put on the clients to leverage the features, though it's really powerful;
• We restrain the supported scope and cherry pick interesting features for our use cases, so it's simpler for consumers, though that's rather limiting.

Put another way, the question becomes should we drive this development by the ES scope (and API), or should be drive it by our own needs (our API)?.

I don't have a clear answer to that, both have pros and cons. And I don't know enough of ES to answer that definitely. There's probably a middle ground and #35 shows the path: picking simple yet powerful features of ES and expose them when they're super nice for clients to consume.

One thing that I'd have loved seeing personally is to keep the existing Kinto response formats ({data: [], last_modified}, the Total-Records and Next-Page headers, etc) so that existing clients would mostly have to deal with the request part. Of course for things like aggregates we'd probably need to add a dedicated section along data, but that would probably scale better at the time of consumption.

But that may be hard and too limiting for what others have in mind for this plugin, and this might be a lot of supplementary effort to put on server side development. So I don't know.

[leplatrem]

Reformatting the results of a search to mimic a classic /records endpoint is trivial. Aggregation can be sorted out too.

However, the pagination aspect can be hard or impossible depending how it is done on ES.