My FHIR Rest API can search and return FHIR resources like [Patient] and [Encounter]. When a search for resources is done, there are instances where no data is found. In such cases, what is the FHIR resource I can send to specify that there is NO data for the search?
The response to a FHIR search should be a Bundle resource with "type": "searchset". You can find the relevant section of the spec here. If the search has no results you should simply return a Bundle with an empty entry list, and "total": 0
Related
I am doing a file.list in the google drive api
GET https://www.googleapis.com/drive/v3/files?access_token=XXXX
This is working fine but its only returning four fields for each of the files in the list
"kind": "drive#file",
"id": "1x8-vD-XiXEEA5Spf3qp8x2wltablGF22Lpwup8VtxNY",
"name": "Experts Activity Dump go/ExpertsActivities",
"mimeType": "application/vnd.google-apps.spreadsheet"
The documentation states that it should be returning a full file resource for each file but its not.
The only thing i have been able to do is to do a file.get on each of the files to get additional information.
This was an old issue that appears to have been fixed now.
GET https://www.googleapis.com/drive/v3/files?fields=*&access_token=XXXX
by sending fields=* you can now see a full file.resorce response for each of the files in the list. It is no longer necessary to do a file.get for each file.
That being said its probably a good idea to limit the fields to those you actually need
This is the intended behaviour of the API. For reference, you may see here the explanation next to the "fields" parameter:
The paths of the fields you want included in the response. If not specified, the response includes a default set of fields specific to this method. For development you can use the special value * to return all fields, but you'll achieve greater performance by only selecting the fields you need. For more information see the partial responses documentation.
For this api, the default fields are indeed kind, id, name and mimeType.
It is recommended that you limit the fields (using the aforementioned parameter) to the ones you need, as it will yield a considerable performance difference.
Graphql always returns:
{
"data": {},
"errors": []
}
Is it possible to also return a custom message?
{
"data": {},
"errors": [],
"messages": [] // or with another key
}
If not, would tools like GraphiQL or other libs fail if we we would add this as a custom feat?
The spec states that a GraphQL response should be a map with a data key, as well as an error key if any errors were encountered. However, it also provides for an optional third key -- extensions:
The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value. This entry is reserved for implementors to extend the protocol however they see fit, and hence there are no additional restrictions on its contents.
To ensure future changes to the protocol do not break existing servers and clients, the top level response map must not contain any entries other than the three described above.
If you're going to include any additional data in the response, it would therefore be advisable to include it under extensions. You can see this done with a number of libraries that implement features like cache control, tracing and cost analysis. If you're using express-graphql or apollo-server on the backend, both libraries allow you to specifically configure extensions used by your endpoint.
FHIR stu3
tried this:
http://fhirtest.uhn.ca/baseDstu3/PlanDefinition/20630?_revinclude=ActivityDefinition
based on the example from :
http://build.fhir.org/search.html#include
but it returned 400 Bad Request
thanks
There are 4 issues with your syntax:
_revinclude is a parameter for the search operation. Searches use the "type" endpoint (i.e. [base]/[resource]). Your format is for a read ([base]/[resource]/[id]). Reads only return a single resource, not a bundle and they don't take most parameters (you can do _format, but that's about it)
_revinclude needs to identify both the resource and the search parameter. E.g. ActivityDefinition:plandefinition, not just ActivityDefinition
The reference in the resources isn't from ActivityDefinition to PlanDefinition, but from PlanDefinition to ActivityDefinition. So you don't actually need a reverse-include. A simple _include is what you need given that your focus is already PlanDefinition
There's no standard search parameter on PlanDefinition to search based on ActivityDefinitions - and both _include and _revinclude are based on search parameters (because that's what servers index).
Because of the 4th issue, you're not going to be able to execute this test against any of the public test servers - unless you make special arrangements, they only support core search criteria. However, on your own system, you're free to define your own search criteria. If you were to do that, you ought to be able to make the query work using the following url:
[base]/PlanDefinition?_id=20630&_include=activitydefinition
(Assuming that you've named your custom search criteria having a path of PlanDefinition.activity.activityDefinition as having a name of "activitydefinition")
According to the Soundcloud documentation (https://developers.soundcloud.com/docs/api/guide#search,
"Some resource types, such as sounds, can be filtered by fields like
license, duration or tag_list."
Is there some list in existence of what attributes can be filtered like this? For example, say I want to find artists with the name of 'billy' that have between 100 and 1000 followers. I would expect I could do (using the Ruby client)
client.get('/users', q:'billy', followers_count: {from:1000, to:10000})
But those followers_count limits are not respected in the results. Why not?
The page you link says
For a complete list of search fields and filters, please see the API Reference for the resource type you'd like to search.
I'm new beginner of Elastic Search. One feature I found is that elastic search documents is particularly expressed in JSON. I google a while but I can not found any reason about that.
Can someone help to explain why JSON not XML or other format?
It is because json document has key, value structure and it helps elasticsearch to index on basis of keys. Suppose if there is an XML, then a lot of effort will be required to just parse the data whereas in json , according to key value elastic search can directly index the required data.
Basically there are mainly 2 standard ways to transport data between a server and client, XML and JSON. Old services use XML as well as JSON as a way to transfer data as most of the old consumers of the services are stick to XML parsers, but recent services use JSON as a standard mainly because of simplicity that comes with JSON. JSON parsers are easy to build and use. At the same time XML parsers needs to be customized as per fields. Although there are some great libraries for parsing a XML response like SAX parser in JAVA, its still not that straight forward. Also JSON can be directly used in javascript. I hope I have answered your question.