So, I'm building an application in Angular which would leverage a REST API at the back, running on Node. I'm having some trouble handling the data complexity while designing this API and could use some help.
Here are the different resources, in question.
Now, here are some of the operations that the application may carry out, so the requirements from the API are clear.
Remember, the request could naturally be a POST, GET, DELETE or PUT. Now, here is where I am so far. I'm only mentioning the URL, the operation on each when sent a POST, GET, DELETE or PUT is self-explanatory.
/doctors/
/doctors/:id
/doctors/:id/patients
(returns a list of /patient/:id
) /doctors/:id/appointments
/patients/
/patients/:id
/patients/:id/doctors
(returns a list of /doctors/:id
) /patients/:id/appointments
Now, I'm okay with the ones above. Here are my questions.
/doctors/:id/patients/:id/appointments
? /doctors/:id/appointments/:id
or /patients/:id/appointments/:id
doesn't feel quite right. I feel like too much nesting is going on. Please help.
Your list of endpoints looks good. I guess there can be different opinions about what you asked.
The following are my opinions about what could be done:
How do I design a URL for task number 7 without having nesting like
/doctors/:id/patients/:id/appointments
?
I would suppose a collection of reminders would exist and define it as follows:
/doctors/:doctorid/reminders
/doctors/:doctorid/reminders/:patientid
Also, I can get all appointments for a doctor or for a patient quite easily with the above. What about particular appointments? /doctors/:id/appointments/:id or /patients/:id/appointments/:id doesn't feel quite right.
There is no need to complicate the endpoints to that level. If you already know the appointment id why would you reach it through the doctors or patients endpoints? It does not not matter, you reach the item directly through its collection.
/appointments/:appointmentid
Also, what about appointments to see a particular patient or a particular doctor?
You can leverage the power of query parameters for this kind of thing. Not everything has be part of the URL template. Features like filtering of specific records could be added to the query parameters instead. For instance
/doctors/:doctorid/appointments?pantientName=
/patients/:patientid/appointments?doctorName=
And what about appointments for each doctor or patient on a particular date?
Same thing here, you could something like:
/patients/:patientid/appointments?from=&to
Or have special endpoints for very well know cases like, my appointments for today, for this week, for this month:
/patients/:patientid/appointments/:year
/patients/:patientid/appointments/:year/:month
/patients/:patientid/appointments/:year/:month/:day
These latter could actually reuse the same logic used to implement the one getting appointments between a range of dates.
The URI structure is not a REST concern, because according to the uniform interface constraint it has to be decoupled from the client.
What matters:
How do I design a URL for task number 7 without having nesting like /doctors/:id/patients/:id/appointments?
You can map reduce the existing appointment collection, like so:
/appointments?doctor=1&patient=1
/appointments/doctor:1/patient:1
And what about appointments for each doctor or patient on a particular date?
You can use a date filter to do that:
/appointments?date=2014-09-02
/appointments/date:2014-09-02
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.