This is an example resource tree.
I need to retrieve latest 48 hours' data of cnt-2 and cnt-0 all together. What kind of query string should I put to the request ?
/in-cse
/in-cse/ae-123
/in-cse/cnt-2
/in-cse/cin-21
/in-cse/cin-22
/in-cse/cin-23
/in-cse/ae-124
/in-cse/cnt-0
/in-cse/cin-01
/in-cse/cin-02
/in-cse/cin-03
/in-cse/cnt-1
/in-cse/cin-11
/in-cse/cin-22
/in-cse/cin-33
Where should I put the ids of cnt-0 and cnt-2 in the querystring ?
/onem2m/api/v1/~/in-cse?fu=2&crb=20190808T000000&cra=20190806T000000&ty=4
Also should I use only querystring to make discovery or is it valid to make a POST request ?
With the example request in your question you will also get all the matching <contentInstance> resources of cnt-1, because you do the discovery on the level of the IN-CSE. Unfortunately, you cannot have multiple targets in a single request, but I see at least two solutions that could work for your use case:
You can add labels two <contentInstance> resources and add label to your search.
/onem2m/api/v1/~/in-cse?fu=2&crb=20190808T000000&cra=20190806T000000&label=myLabel&ty=4
You can add a <group> that contains the <container> resources that are important to your use case (ie. cnt-0 and cnt-2) and make the <group>'s fanoutPoint the target of your discovery request. The CSE is then responsible to redirect the discovery to each member of the <group>.
/onem2m/api/v1/~/in-cse/aGroup/fopt?fu=2&crb=20190808T000000&cra=20190806T000000&ty=4
In my opinion the second method is the more "elegant" one because it makes the (application) relationship of the two <container> resources clearer , but the first one might also be feasible if your <contentInstance> resources are tagged using labels anyway.
Regarding the POST request: For the HTTP binding query parameters are only allowed for filtering and discovery. Please have a look at TS-0009, section 6.2.2.2 Query component.
Btw, there are currently ongoing discussions in oneM2M to describe the differences between retrieval and discovery a bit better.
Related
I am pondering about schema design with regard to explicit vs implicit relation when to...
for example:
in an imaginary schema with 2 custom types author and post, each with several properties, A post type can reference an author in 1 of 2 ways:
explicit: having an Autor type property
implicit: having a scalar value that indirectly points to the author
when designing a shema. what should be my compass in this kind of desicion making?
thanks in advance
There's absolutely no value to the client in only returning the ID of a related resource when you could just expose a field that would return the entire resource. Exposing only the ID will mean the client will have to make subsequent requests to your service to fetch the related resources, instead of being able to fetch the entire data graph in one request.
In the context of other services, like a REST API, it might make sense to only return the ID or URL of a related resource. This is because in those cases, the payload is of a fixed size, so returning every related resource by default can quickly and unnecessarily bloat a response. In GraphQL, however, request payloads are client-driven so this is not a concern -- the client will always get exactly what it asks for. If the client needs only the author's ID, they may still fetch just that field through the author field -- while allowing a more complete Author object to be fetched in other requests or by other clients.
Did the Explain endpoint ever support search_type: dfs_query_then_fetch? If it does now (I'm on 7.1), how do I specify it?
I was thrown for a loop when using the Explain API on two identical documents, but seeing different score calculations. Learning the documents lived in different shards, and that the TF/IDF inputs were calculated per-shard explained the difference. Using dfs_query_then_fetch on the Search API normalized the scores, but the ElasticSearch .net client (both LowLevel and NEST) don't appear to expose a way to specify it for calls to the Explain API.
I also tried to form a request manually, passing it as a querystring or request body parameter. Both fail saying the argument is invalid. I thought perhaps the Explain endpoint didn't offer a way to specify dfs_query_then_fetch, but digging through some old issues it appears that it at least did at some point:
https://github.com/elastic/elasticsearch/issues/2612
Search type is not supported on the explain API. An approach that might work would be to use the Search API with dfs_query_then_fetch and explain, with a compound query that filters only to the document you're interested in (using IdsQuery), along with the query you want the explanation for.
My partner and I are developing a webapp and we expose our Spring backend logic as a Restful API. Our classes have various Many-to-one/one-to-many relationships but not all Frontend use cases require all pieces of information within a class.
Case in point: say [GET] /api/v1/person returns a list of people. The call also supports sorting and pagination through the pageSize, page, sortColumn and sortDirection params. When retrieving person objects, some frontend features require only id and name, others require more details and the final set of features require the full details (including one-to-many relationship objects).
There seem to be 2 ways to implement this - either make 3 specific calls that return the desired #JsonView() data
[GET] /api/v1/person/feature1
[GET] /api/v1/person/feature2
[GET] /api/v1/person/feature3
or allow for one additional view param that lets the user pick the particular view they need for a given request
[GET] /api/v1/person?view=basic
[GET] /api/v1/person?view=detailed
[GET] /api/v1/person?view=full
At the moment we've picked the second approach as it seems to provide more flexibility. Also it reduces the number of REST controller methods we need to maintain.
So my question is whether there is a best practice on this matter. Passing the view param seems very flexible but at the same time it doesn't seem anyone else is using this approach so we figured maybe we are doing something wrong.
Just wanted to check if there is a well established "correct" way of filtering the columns of your result objects - separate specific calls or a general API call that takes in a view parameter.
Thanks in advance!
Is it possible with a FHIR search procedure to search for TWO resource types and sort them according to the date? I'd like a list of Observation and QuestionnareResponses, in a single response, returning the newest 10 regardless of resource type.
Searching for one would be:
http://apps.ehelselab.com/baseDstu2/Observation?_sort:desc=date
Any query using the standard "search" capability is always against exactly one resource type. You can include referencing and referenced resources, but filtering and sorting are always done against the "base" resource for the search. To do what you're interested in doing, you have a few options:
define a custom query using the OperationDefinition mechanism (only works if you've got a direct relationship between client and server systems so you can ensure all participants support the operation
Use a "Batch" to execute queries against both, then interpolate the results as you page through both result sets
You can do a query just on the "base", however there isn't presently a way to constrain the types of resources returned - you'd need a custom search criteria
You might be able to use the _filter mechanism - I haven't dived into it very deeply. But I suspect that it also uses the "single target resource type" approach.
The best bet is probably #3. If you submit a request to add a search criteria to "Resource" allowing constraining the resource type, that would probably let you do what you wanted.
When I call communityService.getMyCommunities(params) or communityService.getPublicCommunities(params) or communityService.getSubCommunities(parentCommunity, params) I would expect that filling params with e. g. tags=[mytag,yourtag] the call would only lookup communities having at least one of these tags (or both, however).
But to me it looks like this param ("tags") is simply ignored, and I always receive all communities of the given category (my / public / sub).
In case of having lots of communities of the requested category this massively slows down performance when I only want to retrieve communities with e. g. one certain tag: I receive all data over the net and must filter / lookup the received object list locally.
What am I doing wrong?
Is there something missing in the SDK implementation?
As part of the communities/my api, you cannot do any filtering... you need to use Search APIs.
In order to get a filtered list of communities based on the tags, you need to make a request to the following URL.
https://apps.na.collabserv.com/search/atom/mysearch?scope=personalOnly&scope=communities&query=&constraint={%22type%22%3A%22category%22%2C%22values%22%3A[%22Tag%2Fprb%22]}&page=1&pageSize=10
Yes, it is URL encoded, you can then change prb to match your tag, and you can repeat the constraints for each tag
You can also reference Link to Search API Constraints