I want to know if is it possible define in FHIR a strategy about read / write specific resource field.
i.e. I have a ServiceRequest resource.
I want to grant for a specific profile / role write on authoredOn field and I want to prevent the write for another profile / role.
I try to read CapabilitySystem resource but I think it don't fit my aim.
In FHIR, in which part of it, I can define profiles and roles?
In general, updates are to the whole resource, not to individual fields. You're free to define business rules that reject an update on the grounds that a field has changed that a user isn't authorized to manipulate, but there's no standard way to express this limitation in the CapabilityStatement. (You could define an extension though.)
Related
I've implemented a GET request as followed:
https://api.com/invoices?filter[status]=paid&include=client
Current situation: Fetch invoices with status 'paid' & include client data for each invoice record
Now, I'd like to instruct my API to include additional data for each invoice record. This additional data is not really related to the invoice. (for example a log record of the last login of the client)
Desired: What are the best practices here? Which query param should I add according to industry standards, to instruct the request to include this additional data, as I wouldn't like to execute a query per invoice to fetch the last login for the client
How to instruct REST API to include additional data for given resource
Spelling check; as far as REST is concerned, you aren't asking for a given resource with additional data, you are asking for a different resource. There's no particular reason that this new resource needs an identifier related to the existing one.
What are the best practices here?
Think about how you would do it with a web site.
The URI would be created by presenting a form to the user, with input elements to allow the client to specify the values in the query string. In other words, the form is playing the role of a URI Template.
So to give the consumer additional control, you would include a new input control in the form - it might be a free text field, or it might be something like a list control which enumerates specific possible values.
Which query param should I add according to industry standards
There are a couple possibilities.
You could review the list of IANA Link Relations, to see if there is a close match. Technically, link relations aren't query parameters. But what this list does is match spellings with semantics, which is what you really want: is there a common understanding of foobar that you can leverage for your own needs.
Another possibility is to look in resources like schema.org, which again has lots of interesting mappings between spelling and semantics.
I happen to know off the top of my head that the EventStore API uses embed with different values to allow the client to specify that it wants to access resources with richer information; but to the best of my knowledge that choice was arbitrary, not based on any real "industry standard".
how about this,
example :
// your code here
$result; // your variable that will send by your API
$user = User::all(); // your additional query to be included to your response API
// additional data example all user data
$result['user'] = $user;
I'm looking for an opinion about defining contract for standard GET/PUT/POST/DELETE methods.
We have resource, let's say Client, so route will be /clients
However, we have two types of id for the client. One is the ID generated by our system. On top of that we want optionally allow customers use external id, generated by customer themselves.
So, if customer never going to add clients to the system, don't really interested about integration, and need only use method GET to read customer, endpoint will be:
/clients/{id}
However, if they want full integration, with ability to add clients, and use some their id, we want give them ability to use their own id.
We considered four possible solutions:
1. /clients/external/{externaId}
2. /clients/ext-{externalId}
3. /clients/{externalId}?use-external-id=true
4. /clients/{externalId} with additional header -"use-external-id": true
We are leaning to options 3 and 4 (can be supported simultaneously) but concerns about "restfulness" of such approach. Any opinions on this? What would you choose and why?
REST says nothing about URLs.
How different are internal and external clients? If the only difference is the existence of an externalId property, just use the /clients endpoint and add the property to your client resource. Always assign and use the internal id property in your API, but allow queries to filter by the customer-provided external id also.
How about this:
/clients/client_id/1 - for automatically generated ids
/clients/external_id/d23sa - for filtering on the external_id field
This could be extended to generically filter on any field of a resource and is the approach my company used in developing SlashDB.
I have easily guessable internal identifiers (auto increasing numbers) and I'd like to give my clients access to resources based on these identifiers.
Of cause I cannot provide them with an URL like:
https://example.com/order/13
because they could easily guess how to access order #14 from this URL.
I therefore thought about providing them with a salted hash of the identifier like:
https://example.com/order/4643ef…
where
4643ef… = sha256(13 + 'supersecretsalt')
Is this a good approach from a security perspective?
First of all, your should not be granting access to any resource simply based on a uri. In other words, user A should not be able to access a resource that belongs to user B even if he knows the relevant uri. To mitigate this, you should add some form of authentication and authorization before allowing access to any (confidential?) resources.
That said, if you'd still like to obfuscate the uri, you can probably use a GUID for this instead of generating any kind of hash. Instead, fore each order ID, simply store a GUID together with it, and then look that ID up whenever the GUID is used in an url.
Sidenote: If you do want to let your customers look up some order-details based simply on a url (i.e. without requiring identification), you might at least make the availability of the resource temporary. You can do this by storing e.g. a valid until-date together with the GUID.
Now user A will be able to see info relating to his resource via a url with a guid, but perhaps only for e.g. 3 days. Other users would also be able to access it, but it would be less likely to happen, both because it would be hard to guess the GUID, and because they would only have a 3 day window to do so.
If user A needs to access his resource again later, perhaps you could provide a way to extend the validity of the GUID, or alternatively just provide a new GUID that points to the same resource, but with a different validity date.
Obviously you'll need to thing through whether or not this is realistic / acceptable for your particular situation and security needs.
We are building a REST API with the following resources: Users, UserGroups. Currently we are supporting the following URI's:
/BASEAPI/VERSION/Users/
/BASEAPI/VERSION/Users/{id}/UserGroups
/BASEAPI/VERSION/UserGroups/
/BASEAPI/VERSION/UserGroups/{id}/Users
I like this better than including references in the objects which then have to be pulled on subsequent requests. It also means that we can avoid query params to filter the results. i.e. we don't have to support:
/BASEAPI/VERSION/UserGroups/{id}?user_id={user_id}
The problem is that it doesn't make creation and deletion semantics very clear. i.e. should a DELETE request to:
/BASEAPI/VERSION/Users/{id}/UserGroups/{group_id}
remove the UserGroup, or remove the user from the user group?
We've considered adding:
/BASEAPI/VERSION/UserGroupUsers
But something doesn't quite feel right about that, but maybe it's the best way to go. What do others think are best practices?
You need to figure out how you intend to represent the membership relationship between user and user group. It can be an attribute of the user, an attribute of the group, or a separate resource. Those are the only choices. How users are added to and removed from groups falls out naturally from your choice. Membership management becomes a PUT/DELETE to the user, the group, or the membership resource.
Personally, I find the separate resource to be the cleanest way to handle the issue, but you then need query parameters to poll for a specific user or group. Also, you'd need to change your second-level resource names, because it makes no sense for /userGroups/{id}/users to return a collection of userGroupUsers resources.
A URL addresses a resource. A GET on this URL returns the resource and a DELETE deletes it. If the DELETE would delete something different than the GET is returning something really is broken.
So if /BASEAPI/VERSION/Users/4711/UserGroups would return the UserGroups with the ID 0815 and 0816 the DELETE should delete both userGroups.
Question is: Does this make sense? What is happening to the other users in both userGroups?
If you want to remove a user from a group I would provide a PATCH Method.
Would it be viable to use an embedded document roles field for a user table if at most there can be 5 different roles? The reason I ask this is because I believe using an array type for that field would do the same thing. The only time I'd be using the roles field is for checking if the user has the ability to access certain pages/functionality on the website. Am I missing something here? Thanks
I don't really think either approach is incorrect and I think it's more relevant to how you want your models to look than how your data will be stored. It really just depends on what (if any) information aside from the role type that you want to persist and how you plan to check the user's role.
If you're looking to simply store a list of roles (admin, user, moderator, etc) then a serialized array attribute is probably fine. On the other hand, if your roles have more information stored within them (ex. granted actions or privileges for each role) it might be beneficial to build out a UserRole model separately and embed that in your User model.
There is actually another, pretty good option if you're simply storing a list of roles where each user can be a member of one or more roles. You can actually us a bitmask. Using this approach your user roles would be stored as a simple integer and you'd use some of ruby's bitwise operators to map that value to a set of roles.
http://railscasts.com/episodes/189-embedded-association?view=asciicast