When it comes to RESTful implementations FHIR spec is very clear on how to construct the URL(s)
VERB [base]/[type]/[id] {?_format=[mime-type]}
VERB: The first word is the HTTP verb used for the interaction
Content surrounded by [] is mandatory, and will be replaced by the string literal identified. Possible insertion values:
base: The Service Root URL
type: The name of a resource type (e.g. “Appointment”)
id: The Logical Id of a resource
etc.
I was wondering if its okay to Customize the resource Naming in the URL for it to be more meaningful to the consuming application.
E.g. VERB [base]/[type]/[id] {?_format=[mime-type]}
Type being TransportAppointment / HomeCareAppointment / ResidentialCareAppoinment so the URL would look like
E.g. VERB [base]/HomeCareAppointment/[id] {?_format=[mime-type]}
E.g. VERB [base]/TransportAppointment[id] {?_format=[mime-type]}
Where each will return the resource of the Type Appointment. with different Types
Sure, you can do always do what you are proposing, but it wouldn’t be conformant to the specification. That probably means it’s not “okay” in the terms of your original question.
There’s a reason why we don’t do this, btw - this is a name that implies something about the contents of the resource that the URL refers to. If you search Appointments, are the different kinds of resources found? if they are, what is their master URL? do they have more than one? Note that we define a compartment based search as syntactical sugar for a search. We considered extending the same approach to the URLS of the resources, and elected not to because it creates difficult to manage problems when 2 different URLs refer to the same content. (even the compartment based search is getting less popular recently). The many issues that this raises may be managable for you, so it might make sense … but it still won’t be conformant.
1 Like
thanks for the reply, i partly understood the answer, could you kindly explain what you meant when you asked what is their Master URL?
well if you search for appointments no they would not get different kinds of resources, resource type will always be “Appointment” but with different type [transport, homecare etc.]. And by master URL you meant its compartment?
if that is the case yes they will have more than one.
Practioner/[id]/HomecareAppointment
Patient/[id]/HomeCareAppointment
Patient/[id]/TransportAppointment
I fail to any see problems with approach at present, but if you see any issues in advance appriciate the feedback.
Master URL = the URL you know a resource by / use to update it. It’s a bad idea for a single logical resource to be known updated by more than one URL. It may be that there’s never any need for this in your context, and that there’s never a need to treat all appointments, whatever their type, as a single group, in which case the scheme you’re proposing will probably work… but those are the reasons we don’t do it as a part of the specification
1 Like