通过不同的用例为RESTful API模型和端点建模

时间:2019-03-04 19:43:56

标签: rest domain-driven-design api-design restful-url nested-resources

我对该主题有些困惑,所以我想对此提出一个问题。如今,RESTful设计正在设法在世界上获得更多的空间,人们确实已经习惯了范式和HTTP动词,资源等不成文的规则。我只想清楚地了解这一点。

我正在阅读一些有关该主题的书,这已经很清楚了,但是复杂的用例可能需要更多的时间来计划和设计。 Kirsten Hunters-我认为Irrestible API是一个很好的API,这本书指出每个API都有自己的用例,因此在过去的几周中,我试图围绕用例对我的API进行建模,但是我会提出一些问题希望表现出希望,我会得到一些很酷的想法和建议,以供将来继续使用。

有一个系统,称为众议院联合会(House Federation),该域非常容易且完全可以理解,关系也是如此。 在这个小应用程序中,您可以在3个不同的屏幕上保存多达3个不同的实体。

在一个屏幕上,您可以列出和挑选房屋以及一些信息。 在另一项上,您可以列出并选择要出租房屋的居民。 在第三个清单上,您可以列出和提取租赁,租赁将包含有关租赁房屋和承租人的信息。

域实体如下:

房屋: enter image description here

居民(出租人): enter image description here

租赁: enter image description here

正如您所看到的那样,领域并不那么复杂,真正令人惊讶的是,房屋和居民实体是可变的,而租赁是不变的。这是什么意思?一旦在数据库中插入新的租赁,并且如果您更改房屋街道或街道编号(可能发生的话),它们就不会通过数据库中的外键联接在一起。租赁表将始终包含之前插入的数据,因此它总是复制的,依此类推。

我首先提到列表屏幕和详细屏幕共有3个屏幕(x2)。 在房屋列表上,您可以从数据库中列出房屋。对于此给定的用例,我们使用此端点POST / houses / query-我们将查询词用作资源,因为我们正在验证传入的请求,该请求用于请求房屋,它包含有关SQL的WHERE条件和分页等字段。 我们使用POST / houses端点创建一个新端点。

我们使用POST / residents / query查询居民,并使用POST / residents创建新居民。

我们使用POST / leases / query来查询租约,并使用POST / leases创建新的租约。

查询词可能会破坏RESTful规则,但是该词可以用作名词,因此我们仍然在这里:D

因此,这些用例就是这些正确知道的,列出(查询)和创建的用例。如此简单(如果您想抱怨基于POST的列表,请在我们在后端创建查询资源并且响应是基于传入条件的模型列表时考虑一下。)

因此,在我可以解释一下我的模型,用例和我的小应用程序的目标之后,这就是我的问题。

在租约详细信息屏幕上,我可以插入新的租约以提供房屋和居民的数据,这将有一个util函数,这将是一些自动完成字段,可以查询房屋和居民的模型。

我的问题是我将能够使用已经提到的端点/ house / query或/ resident / query-但是这些端点会生成较少的数据,我的意思是在列表屏幕上,我不会从中返回所有给定的字段给定的域(也许我会跳过居民的性别),并且只包含2-3列。但是在插入屏幕上,我需要新租赁实体的所有数据。

我的问题是在用例中如何将这些模型彼此分开? 我应该如何命名我的资源/端点? 我正在考虑命名将由自动完成功能使用的端点,如下所示:

  • POST / houses / query / lease->租赁词将显示自动完成功能或POST / houses / query / autocomple

  • 将在租赁屏幕上使用该词>
  • POST / residents / query / lease->租赁词将显示自动完成功能或POST / residents / query / autocomple

  • 将在租赁屏幕上使用该词>

虽然我对这个话题的了解越来越多,但是随着话题的扩大,在阅读了更多有关该话题的信息后,我变得更加困惑,有人说这有些人在说另外一件事。

我想看清楚,但是我不知道有时候哪种方法是正确的。 我试图围绕用例对我的API模型进行建模,并尝试不将它们与数据库中的真实实体联系起来。

欢迎各种答案和建议,我想清楚了解这个主题:)

0 个答案:

没有答案