我正在开发一个有很多大型模型的应用程序。计算基表和所有相关表，现在大约有30个表用于描述房地产属性。
所以，基于REST，我必须拥有30个子路由才能更新每个相关模型的属性。
/属性 /属性/ 1 /属性/ 1 /可用性 /属性/ 1 /表面 /属性/ 1 /额外 /属性/ 1 /图像
...
一个房产真的有很多相关的东西，相信我。
现在上面这个设计看起来非常酷，但是当谈到使用它时，它的迁移有点麻烦。
我有2个客户，一个是内部公司仪表板，另一个是我们用户的仪表板。
他们可以很好地查看附加到属性的所有内容，并可以通过更改表单字段中的数据并单击“提交”来修改它。
现在我正在混合他们所谓的一点：
细粒度CRUD资源与粗粒度资源
这意味着您可以使用巨大的JSON对象POST / properties / 1并更改一些相关模型。
如果我应用完美的REST API设计，每次用户点击保存按钮时，我最终会发出30个请求。
通过向主资源（/ properties / 1）发出PUT请求而不是“properties / 1”，更新相关模型（假设您可以更改一些基本数据以及附加信息和图像的可用性）是否正确？ /图像“？
不确定这是否与stackoverflow直接相关。如果不是，我会事先道歉。
答案 0 :(得分：0)
所以，基于REST，我必须拥有30个子路由才能更新每个相关模型的属性。
设计REST API时最重要的问题
我如何将其作为网站？
如果您的答案是：＆＃34;我会有30个不同的页面，客户可以加载和修改＆＃34;，然后自己敲门。
您可能发现应用task based ui的原则会有所帮助。
通过向主资源（/ properties / 1）发出PUT请求而不是更新相关模型（让我们说你可以改变一些基本数据，还有可用的附加内容和图像）是否正确＆＃34;属性/ 1 /图像＆＃34;？
正如Roman Vottner已经注意到的那样 - 是的，RFC 7231明确表示修改一个资源会在其他地方产生副作用。从根本上说，HTTP描述语义，而不是实现。你在黑匣子里做什么取决于你 - 唯一的限制是交换的信息及其解释。
HTTP关于更新模型的方式比关于修改无效的缓存表示的关注要少得多。