我是一个新手，但正在努力实现这个交互式应用程序，我正在研究"正确的方式"，或者至少在可扩展性、可维护性、模块化、开发速度和工具独立性方面是一种好方法。这就是为什么我选择了REST设计指南和实现MVC的框架。
但是，我无法弄清楚在以下情况下将什么放在哪里，并且来自更有经验的开发人员在此技术中的任何输入或阅读材料将不胜感激：
我正在开发一个单页 Web 应用程序，该应用程序创建一个包含多个嵌套资源的资源。在创建方法等中，我需要从嵌套资源调用创建方法。现在，每个GET请求都以JSON响应，然后前端相应地解析，显示并动态添加到页面中。问题是：这应该从嵌套资源创建和存储方法的什么位置，在控制器中还是在模型中？
目前，我的方法是：由于控制器函数是处理用户输入，与模型交互并相应地返回视图，因此嵌套存储方法位于模型中，因为它们不是独立创建的，它们的创建方法位于控制器中，因为它们是从 ajax 调用请求的，但这不是嵌套的，依此类推。我担心这太混了，不一般。
我还好吗？我混了吗？我不想把事情搞得一团糟，让我的同事理解。理论在应用时变得棘手。
我要试一试。我自己也还在学习这个，所以如果有任何信息有误，请纠正我。
在可伸缩性方面，您应该始终能够独立创建任何模型，即使此时它似乎不是绝对必要的。REST 范式正是代表这一点：每个模型(也称为资源)都有自己的(子)一组 CRUD 端点，客户端应用程序可以使用这些端点对任何数据组合(其中基本实体主要是您指定的模型的组合)执行任何操作。
此外，模型应仅关注其自己的数据，并且该数据通常位于单个表中(对于关系数据存储)。在许多情况下，模型指定用于读取相关资源的设施，以便在请求时可以包含此数据。这可能类似于下面的行，理想情况下响应完全符合 JSON API 规范：
GET //api/my-resources/1?include=related-resource
但是，模型不应该创建(POST)，更新(PUT)或删除(DELETE)这些关系，如果没有明确的指示，则完全不能这样做。
如果您有一个一次性创建模型及其嵌套模型(我假设相关模型)的过程，则可以为此操作创建一个额外的终结点。您必须为这组资源想出一个合理的名称，并在整个应用程序的HTTP/支持层中使用它。例如，对于创建这样的集合，请求可能是：
POST //api/sensible-name { your: 'data' }
保持{ your: 'data' }部分尽可能接近典型的 JSON API 格式，最好完全兼容。然后，在你的后端(我想是Laravel，在你的案例中)，你需要创建一个可能被称为<SensibleName>Factory的工厂实现，负责弄清楚如何将发布的数据映射到不同的模型，以及如何指定它们的关系。在引擎盖下，这家工厂只是使用模型类的创建工具将您带到您想去的地方。
当您在模型中自动执行此过程时，将无法独立创建资源。
当您改为在任何不符合 REST 范例的单资源控制器中自动执行此过程时。
对于工厂模式，您可以显式使用该类来执行更高级别的操作，并且上述问题都不适用，更不用说此方法是否符合 REST。
关键要点是，当您确实希望一次性创建多个记录时，通过对单资源终结点执行多个请求，仍然必须通过对单资源终结点执行多个请求来实现完全相同的结果，并且为了方便起见，额外的/api/sensible-name终结点只是代替了调用这些多个终结点的需要。
请注意，我的语句与创建哪些端点以获取嵌套资源几乎没有关系。这个SO问题有一些很好的对话，关于什么是可以接受的，以及你的具体需求可能与此有何关系。
最后，这完全是关于什么对你和你的应用程序有用，而REST等只是向你提出一种尽可能满足一般Web开发中类似需求的方法的哲学。