为复杂嵌套数据编写REST API [英] Writing a REST API for Complex Nested Data

问题描述

因此，我正在Angular中构建一个应用程序，该应用程序将利用在Node上运行的REST API。我在设计这个API时处理数据复杂性有一些麻烦，可以使用一些帮助。

这里有不同的资源。

1. 医生（每名医生可能有多名病人）


2. 患者（每名患者可能有多名医生）


3. 预约（医生自然约会）


4. 提醒（提醒可能由医生发送给病人，而不是其他方式）

现在，这里是应用程序可能执行的一些操作，因此API的要求是明确的。

$ b每个医生必须能够请求所有患者或特定的患者。

每个病人必须能够请求所有的医生或一个特定的一个。

每个医生必须能够请求所有的约会（以查看所有患者）在特定的日期，或在必要时的所有日子。

每个pa必要时必须能够请求所有的约会（查看所有医生），或者在必要时请求所有日子。

每位医生必须能够请求所有约会

每名患者必须能够从单一医生请求所有的约会。

每位医生必须能够要求对于特定病人的所有提醒。

请记住，该请求自然可以是POST，GET，DELETE或PUT。现在，这里是我到目前为止的地方。我只是提到URL，每次发送POST，GET，DELETE或PUT时的操作是不言自明的。

1. /医生/


2. /医生/：id


3. / doctors /：id / patients （返回一个 / patient /：id 的列表） / li>
   
4. /医生/：id /约会


5. / patients /


6. / patients /：id


7. / patients /：id / doctors （返回一个 / doctors /：id 的列表）


8. / patients /：id /约会

可以和以上一样。这是我的问题。

1. 如何设计任务编号7的URL，而不必像 / doctors / ：id / patients /：id /约会？


2. 此外，我可以很容易地获得医生或病人的所有约会。具体的约会怎么样？ / doctors /：id /约会/：id 或 / patients /：id /约会/：id 感觉挺正确的。


3. 另外，约会是要看病人还是特定的医生呢？


4. 每位医生或病人的约会在特定的日期？

我觉得太多的嵌套正在发生。请帮助。

解决方案

您的端点列表看起来不错。我想对您所问的问题可能会有不同的看法。

以下是我对于做什么的看法：

如果没有像 / doctors /：id / patients /：id /约会这样的嵌套，我如何设计任务号7的URL？

我会假设一系列提醒将存在，并定义如下：

  /医生/：doctorid /提醒
 /医生/：doctorid /提醒/：patientid 
  

此外，我可以很容易地获得医生或病人的所有约会。具体的约会怎么样？
/医生/：id /约会/：id或/ patients /：id /约会/：id
感觉不太合适

没有必要使端点复杂到该级别。如果您已经知道预约号码，为什么要通过医生或病人终点接触？没有关系，您直接通过收集到达该项目。

  /约会/：约会
  





此外，约会可以看到特定病人或特定医生呢？

您可以利用查询参数的强大功能进行这种处理。不是一切都是URL模板的一部分。可以将特定记录的过滤功能添加到查询参数中。例如

  /医生/：doctorid /约会？pantientName = 
 / patients /：patientid /约会？doctorName = 
  





在特定日期，每位医生或病人的约会如何？

同样的事情在这里，你可以像：

  / patients /：patientid /约会？from =& to 
  

或有对于这个月的非常熟悉的案例的特殊终点，例如本周，我本人的任命：

  / patients /：患者/约会/：年
 /患者/：患者/约会/：年/月份
 /患者/：患者/约会/：年/月/月日
  

这些后者实际上可以重用与实现在一系列日期之间约会的逻辑相同的逻辑。

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.

1. Doctors (each doctor may have multiple patients)
2. Patients (each patient may have multiple doctors)
3. Appointments (appointments exist for doctors, naturally)
4. Reminders (reminders may be sent from doctors to patients, not the other way around)

Now, here are some of the operations that the application may carry out, so the requirements from the API are clear.

1. Each doctor must be able to request for all his patients or a particular one.
2. Each patient must be able to request for all his doctors or a particular one.
3. Each doctor must be able to request for all his appointments (to see all patients) for a particular date, or for all days, if necessary.
4. Each patient must be able to request for all his appointments (to see all doctors) for a particular date, or for all days, if necessary.
5. Each doctor must be able to request for all appointments from a single patient.
6. Each patient must be able to request for all his appointments from a single doctor.
7. Each doctor must be able to request for all his reminders to a particular patient.

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.

1. /doctors/
2. /doctors/:id
3. /doctors/:id/patients (returns a list of /patient/:id)
4. /doctors/:id/appointments
5. /patients/
6. /patients/:id
7. /patients/:id/doctors (returns a list of /doctors/:id)
8. /patients/:id/appointments

Now, I'm okay with the ones above. Here are my questions.

1. How do I design a URL for task number 7 without having nesting like /doctors/:id/patients/:id/appointments?
2. 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.
3. Also, what about appointments to see a particular patient or a particular doctor?
4. And what about appointments for each doctor or patient on a particular date?

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.

这篇关于为复杂嵌套数据编写REST API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！