if there is a resource for the given URI, update it according to the request.
if there is no any resources for the given URI, create a new resource with the given URI.
A sample PUT request on FHIR : ws/fhir/Person/e6bbecc5-5b87-49a2-85ad-008bd7d9rrrr
So we need to create a new Perosn Resource if no Persons are associated with e6bbecc5-5b87-49a2-85ad-008bd7d9rrrr(uuid).
But Harsha and I discussed whether we allow an external user to create a Resource with a particular UUID. In another way, will it create any problems by allowing a user to specify the uuid. We would like to know the opinions of the community regarding this.
One of the purported benefits of using UUIDs is that it shouldn’t matter who generates them as long as they are truly version 4 UUIDs (i.e., generated randomly and in the form xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is any hexadecimal digit and y is one of 8, 9, A, or B).
Since we have many examples of workflows that require data generation outside of the server (data created on multiple servers, mobile data generation, etc.), we need to allow a way for UUIDs to be provided by REST clients. I would be thrilled if we restricted these to version 4 UUIDs (i.e., validated that they follow the spec) and it forced us to clean up the pseudo-UUIDs being used within the MVP/CIEL dictionary.
So @harsha89@surangak here we have a positive answer for allowing external users to provide the UUID to the server as long as they comply with version 4 UUID specifications.
@burke agreed that client should create a valid uuid which confirm for particular version of uuid. Otherwise client may create numerous uuid types which is not acceptable. @sashrika shall we do the validation and implement the person update?
I agree that the client should be able to PUT to a specific UUID to create a resource.
For data it’s fine to start enforcing the requirement that the UUID is valid. But I think this is an inappropriate way to force CIEL to change its UUIDs. (So, if FHIR had some mechanism for creating concepts, we would need allow invalid UUIDs.)
Thanks @sashrika for moving forward with this. I agree with what’s been said. Check if the uuid is a valid Version 4 UUID and create a new resource. If not, throw an error.
Make sure you throw runtime exception which comes from hapi library itself. So it will give the response back to the client by wrapping error with OperaionOutcome.
