Custom query parameter support about json-api HOT 5 CLOSED

I created a rather hacky workaround to pass the query parameters through the filter argument by altering the handle method of the controller.

Controller = new API.controllers.API(registry);
Controller.handle = _.wrap(Controller.handle, function(handle, request, frameworkReq, frameworkRes) {
    let filter = request.queryParams.filter;
    let params = _.clone(frameworkReq.query);
    params.filter = filter;
    request.queryParams.filter = {
        simple: params
    };
    return handle.call(this, request, frameworkReq, frameworkRes);
});

from json-api.

Custom query parameters haven't on my agenda so far, but I see the value in supporting them and I'll leave this issue open as a reminder to myself. In a few weeks, I'm going to be be doing a big chunk of work on the library, and I may tackle this.

For your particular issue, though, I think there may be a way to solve it without custom parameters. In particular, I'm wondering: what happens if the user requests /chapter/12345 without the Locale parameter? Do they get back a collection of resources or 404? Also, what do the type and id members look like on the returned resource objects? I'm not sure how you've customized the DB adapter but, I'm pretty sure that, in JSON API terms, /chapter/12345?Locale=en_US and /chapter/12345?Locale=other should return resource objects with different ids. If that's the case, there should be a way—and you'd want—to pass Locale as part of the id to the queries to the adapter, which is already supported.

from json-api.

I use en_us as default locale if none is specified.

So you think the locale should to be part of the ID?
The way I see it, the locale alters the representation of resource (i.e. a translation), but the resource itself is the same (the content nor its meaning change). That's why different translations share a common ID.

My custom DB adapter has nothing to do with the default Mongoose adapter. It translates JSON API requests to another API, so it's actually an API adapter, not a DB adapter.

from json-api.

So you think the locale should to be part of the ID?
The way I see it, the locale alters the representation of resource (i.e. a translation), but the resource itself is the same (the content nor its meaning change). That's why different translations share a common ID.

I think it's a bit of a gray area.

In HTTP terms, your argument makes perfect sense. Taken to it's conclusion, the locale wouldn't be in the URI at all (even as a query parameter) since, from HTTP's perspective, any URI change acts to identify a different resource; instead you'd use one URI with the Content-Language header separating the locales. Most people don't do this, though, because working with Content-Language is a pain. Instead they mint a different URI for each locale. This is more convenient, but it makes HTTP unaware that the different URIs/resources are related (even though a human can tell because of their common base url).

So, I think the baseline argument for giving each localized version a different JSON API resource (in the sense of giving it a different id) is to say that it's analogous to the HTTP case, in that it's a bit less pure but it's more convenient. Beyond that, though, one could argue that using different ids for each localized version actually isn't impure in JSON API terms, since JSON API doesn't really have the distinction between a resource and a representation. (Taking this even further, one could actually argue that because JSON API lacks a resource–representation distinction, this demands giving these different ids, but I'm not sure I'd go that far.)

Anyway, I guess I'm saying that I think you could at least get away with putting the locale in the id. Then, if you want to signal to clients what the other versions are, you could add an alternates relationship, as discussed here that contains the other resources. Finally, if we (the JSON API spec authors) add support for an alternate key in the resource-level "links" bag, which I'd really like to land soon, then you could use that to signal at a semantic level the equivalence between these resources, even though they have different ids (which is exactly what happens at the HTTP level when multiple URIs return documents with rel=alternate links pointing to one another).

from json-api.

I'm gonna close this, as the new Query Transforms feature in v3 makes it possible to read parameters from the request and use them to modify the query that's passed to the db adapter. Here's an example.

from json-api.