什么是构建网站的父/子视图的正确RESTful方式

我有三个实体：BuildingUnitPerson

这些都是纯粹的简单易独家1：M关系

一个Person只能住在（1）单位一个Unit只能存在（1）单位 Building本质上是父母。

如果我有像URL：

视图模式是很容易

/buildings      //Show all buildings 
/buildings/[id]     //Show one building 
/buildings/[id]/units    //Show all units in a building 
/buildings/[id]/units/[id]/people //Show all people in a unit

然而，这似乎有点冗长。虽然这些URL可能适用于重定向到GET的PUTS和POSTS，但是如果我想要显示建筑物中的所有单位和人员，我是否应该使用类似buildings/[id]/details的路线，还是有其他一些标准惯例？

此外，当我想要显示一个窗体来编辑值，是否有一个标准的url路径，如buildings/[id]/edit一个POST和一个PUT在这种情况下基本上会使用相同的形式（但PUT的字段填充出）。

来源

2016-01-08 Armstrongest

我认为你的问题可能会吸引一些有见解的答案，但很高兴听到其他人关于RESTful API设计的做法。

你说你的路似乎那种啰嗦了，你可能有这样的感觉，如果你的ID是自动递增的整数，并指定建筑物，单位等的唯一方法是使用像

buildings/1/units/4/tenants 
buildings/1/units/4/tenants/5

路径我这些都是清晰的界面。如果我必须维护你的代码，我认为这很明显是什么。如果我不得不批评某些东西，我会说你似乎正在以一种允许所有或一种选择的方式发展。不过，这是您的设计选择。也许这正是你在这种情况下需要的。下面是一些想到的例子。

更新一个租户

PUT buildings/1/units/4/tenants/2

创建三个单元

POST buildings/2/units     //carries message body for SQL in back end

读租户特定标准

GET buildings/1/tenants?params=  //GET can't carry a message body

个删除租户一定的标准

DELETE buildings/5/tenants?criteria= //params needed?

来源

2016-01-08 05:17:26 ThisClark

谢谢。是的关于设计选择。在你的第一个例子中，这正是我所谈论的那种东西。我倾向于对'单位/ 4 /租户/ 2'做PUT，因为'租户'实体没有祖父母的“知识”，只有父母的“单位”。如果父母的单位ID被更改，我是否将租户“移动”到另一个实体？我试图找到一些很好的例子来看看API的作用，但正如你所说的，有不同的观点。 – Armstrongest

@Armstrongest你是否熟悉Trello？它由Stack Overflow的共同创建者Joel Spolsky发布。您正在寻找很好的示例 - 我建议您查看Trello API，例如板卡API - https://developers.trello.com/advanced-reference/board，您将看到他们是如何设计API的。 ..它类似于你的，并且有很多例子，我相信你会发现它很有帮助。就此而言，请查看Stack Overflow API以获得更多示例 - https://api.stackexchange.com/docs – ThisClark

谢谢！我会检查一下 – Armstrongest

什么是构建网站的父/子视图的正确RESTful方式

回答

相关问题