I'm building a FHIR client in .NET using the test server in the following request: http://argonaut.healthintersections.com.au/open/Patient?family=Doe&given=John. I am able to successfully return and parse JSON response for an existing test patient. My use case: Now that I know that my patient of interest exists I want to return problems/medications/immunizations for the patient.
Can someone please tell me how I can turn around the patient information (presumably patient id) received in the JSON response and request all medications or immunizations or problems for said patient? I've tried quite a few ways based on my interpretation of the documentation (trying to leverage resource type of StructuredDefinition defined in the specification, but I cannot seem to get it right. Excerpt from the JSON response showing patient id returned from server:
"entry":[
{
"resource":{
"resourceType":"Patient",
"id":"4705152-patient",
"meta":{
"versionId":"1",
"lastUpdated":"2015-05-04T13:41:19Z"
},
Thank you
Two different answers, depending how you want to go about it. If you want to get a dump of the whole patient record, you can do this:
http://argonaut.healthintersections.com.au/open/Patient/475152-patient/$everything. That will give you Lists, Conditions, Allergies, Medications, etc. - everything in the patient compartment for that patient. (You can filter by "since" and a couple of other parameters).
You can also go after the resources individually:
http://argonaut.healthintersections.com.au/open/Condition?patient=475152-patient
Side-note: I just queried the healthintersections argonaut server for the patient id you specified in your example and didn't find it, so I tested my queries using patient "1".
You'll need to be authorized via OAuth in order to get this data back
EDIT: Updated to reflect that non-availability is due to lack of OAuth authentication, not Argonaut intention
You could also use _revinclude to directly include these associated resources in the query response. See the search specification page.
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.
My line o thinking is this:
get evaluations //would retrieve all evaluations of the system. (in practice never used).
post evaluations create a new evaluation
Following the Rest pattern
get evaluations/1 //details of the evaluation with id "1"
But I was using
get evaluation/{product_id}
To retrieve all evaluations of a product.
For what I know of Rest design this is not good. It would be something like this:
evaluations?product_id=5
Now, what it would be an endpoint to retrieve all reviews of a specific client? I am using Auth 2.0.
I am really confused.
Is it possible to shove it all in one controller?
In summary, I would like to know if the endpoint evaluations?product_id=9 is suitable to retrieve all evaluations of a product. And what would be and endpoint to retrieve all evaluations of a client that has a token.
You have many approachs here:
Separate Endpoints:
Suche as:
get /users/{user_id}/evaluations
get /products/{product_ID}/evaluations
get /evaluations/{evaluation_id}
single endpoint
get /evaluations/{type}/{id}
And in your controller implement a logic to retrieve evaluations according to the type (user, product,...) and the id of the selected type.
Personally, I prefer the first one.
Given a unique_email_id, how can I retrieve all list members matching that ID?
I am attempting to use the search-members endpoint, ala what I do for searching email-addresses:
https://us9.api.mailchimp.com/3.0/search-members?query=chris#chris.com
but instead (given a unique_email_id of 4dce5
https://us9.api.mailchimp.com/3.0/search-members?query=4dce5
and I'm getting no results.
Is there another endpoint I'm missing?
However using the query string ?unique_email_id=X attached to the end
of GET lists/list_id/members will pull up anyone with that specific
EUID.
Indeed this works very well. Example :
GET /3.0/lists/dfc3cf4b38/members?unique_email_id=f4b75a9d78&fields=members.email_address
will return :
{"members":[{"email_address":"my_email#hotmail.com"}]}
I've had a chat with the mailchimp support about this issue. This was there response (part of it because not everything discussed in that chat is relevant to this question):
(09:00:04 AM) Mailchimp support: Thanks for hanging in there, Me. It looks like
the email_unique_id can't be searched via API endpoint like it can be
within the app. Another option to get to your goal is GET to
lists/list_id/members with the query string
?fields=members.email_address,members.unique_email_id which should
pull up all their subscribers' emails and unique ids. At that point,
you can filter through those results for the unique id
(09:00:52 AM) Me: Same goes for the user ID I guess?
(09:02:05 AM) Me: Why can't it be searched? When I list ids as well I might miss information. I don't need the unique_email_id in my response, I need to search for it to retrieve user information without getting duplicates in my result
(09:07:11 AM) Mailchimp support: Ok I understand, one
moment while we test this out for you. Thanks again for your patience!
(09:16:22 AM) Mailchimp support: Hey Me, thanks for waiting. I tested the
endpoint lists/list_id/members?unique_email_id=e8da8fa60a and I was
able to return just the one subscriber with that field. Search-Members
only functions the way it does in app where you can only search
specific strings like names, email addresses, but not ids as those
aren't visible in app. However using the query string
?unique_email_id=X attached to the end of GET lists/list_id/members
will pull up anyone with that specific EUID.
I would like to use Mailchimp Api 3.0 to add a subscriber to an automation workflow, but I can't find where the workflow_id or workflow_email_id are located... this is from the documentation:
POST /automations/{workflow_id}/emails/{workflow_email_id}/queue Add a subscriber to a workflow email
http://developer.mailchimp.com/documentation/mailchimp/reference/automations/emails/queue/
Can anyone tell me to find it? It's probably somewhere really obvious. I mean the list_id is well covered, but I can't find any info about this.
I found this confusing as well. Here is how I got the answer:
Send a GET request to https://us9.api.mailchimp.com/3.0/automations to find the workflow_id
With the workflow_id, send a GET request to https://us9.api.mailchimp.com/3.0/automations/<workflow_id>/emails to find the workflow_email_id. The workflow_email_id will be the "id" in the array that's returned.
From there you can make POST requests to https://us9.api.mailchimp.com/3.0/automations/<workflow_id>/emails/<workflow_email_id>/queue
Keep in mind you might need to subscribe an email address to a list first for the post request to work. To subscribe you can use: https://us9.api.mailchimp.com/3.0/lists/<list_id> with your data:
{
"members": [{
"email_address" : "emailaddress#whatever.com",
"status": "subscribed"
}]
}
The answer is found in the official mailchimp knowledge base: It explains that you simply go into the workflow and read the id from the URL.
Other ways to get id information about anything:
Using the API endpoint, detailed here: http://developer.mailchimp.com/documentation/mailchimp/reference/automations/
You'll see that the Response body parameters return everything about the automations, including the id.
Probably the easier way: use the developer playground https://us1.api.mailchimp.com/playground/?_ga=1.218336095.774374564.1480036371
So, once you set up your lists and automations, go into the playground, and you'll find all the ids you'll need for everything.
JSON API REST endpoint with permissions-restricted fields
I am working on a JSON API-compliant REST api. Some endpoints contain fields that should be restricted (read-only or not available) for certain users.
What is the best way to architect the api to allow that certain users have access to certain fields, while others do not? By "best", I mean:
Most compliant with REST standards, ideally JSON API standards
Most clarity in terms of preventing bugs and confusion on behalf of clients consuming the API
I am considering the following options, each with their set of concerns/ questions. I would be more than grateful for any other solutions!
Option 1: Return null on restricted fields for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Lack of distinction between null meaning "null value" and null meaning "You don't have access to this"
In REST/ JSON API architecture, is it okay for an endpoint to return different data per user, based on permissions? I have the impression that this would be contrary to the spirit of resource-based REST architecture, but I could not find anything specific to point to in any doc or standard (e.g. JSON API). Also applies to Option 2.
Is there any paradigm for adding some sort of "You don't have access" flag in the resource's metadata?
Option 2: Exclude restricted fields entirely for users without permissions
Different data values would be returned per-user. Is this strictly anti-REST?
Possibility of "undefined" errors in client, when trying to retrieve field value
Option 3: Move restricted field(s) onto another endpoint, available as an ?include='field_name' relation for those with permission
Example: /api/entity includes attribute field "cost" which is only available to Admin users. Admin users can request cost data via GET /api/entity?include=cost. For all users, "cost" is exposed as a relation in the resource object, with a "type" and "id".
This is the option I am leaning toward. The main con here is endpoint clutter. I have a lot of relations that would need to be made into separate endpoints, simply to support a permissions-quarantined data on an already-existing endpoint.
In the JSON API specs, I am having trouble determining if it's ok for an endpoint to exist as a relation only, e.g. can we have /api/entity/1/cost, but NOT have a top-level api endpoint, /api/cost. My assumption is that if a resource has a "type" (in this case, the relation type being 'cost'), it also has to live on a top-level endpoint.
In this scenario, the client could get a 401: Unauthorized error response if a non-admin user tries to GET /api/entity?include=cost or GET /api/cost/:id
Note: I have already built a separate permissions schema so that the client can determine which CRUD privileges the user has, per top-level endpoint, before making any requests. Permission sets are indexed by resource type.
Any help on the matter would be very much appreciated! And if anything needs to be clarified, feel free to ask.
I would definitely not use undefined or null to indicate fields that the user is not allowed to see. To me, that feels like a lie and represents that the data is really not there. They would have to really know your API in order to get a grasp of what is really going on.
I would recommend something more like your 3rd option, except I would make it a different endpoint altogether. So in your example, the endpoints would be:
/api/entity/1/cost
and for admins
/api/admin/entity/1/cost
or something like that.
This way your server code for the admin endpoint could just be focused on authenticating this admin user and getting them back all the fields that they have visibility on. If a non admin user tries to hit that route, reject them with an unauthorized status code.
I'm not saying that you should not implement the GET param to be able to specify fields as well. You can if you want to, but I don't think it just won't be necessary in this case.