通过 Laravel 构建 RESTful 应用程序的传统方式是啥？

Posted 2023-02-22

【中文标题】通过 Laravel 构建 RESTful 应用程序的传统方式是啥？

【英文标题】：What's the traditional way to build a RESTful App via Laravel?通过 Laravel 构建 RESTful 应用程序的传统方式是什么？

【发布时间】：2017-07-23 09:04:57

【问题描述】：

我将通过 Laravel 和一个我还不确定的客户端框架（可能是 React 或 Vue.js）构建我的第一个 REST 应用程序。

我对如何构建我的应用进行了一些研究，但不幸的是，这让我更加困惑。

我得出的结论是，我可以通过 2 种方式构建我的应用程序：

在同一个项目中构建应用程序。但是，没有Laravel Blade。 将应用分为 2 个项目（正面和背面）。

---

一方面，在同一个项目上构建应用程序的优点：

授予我使用 Laravel Mix 的选项。 Laravel 提供开箱即用的 Vue support。

另一方面，从前到后构建应用程序的优点：

每一方都有自己的单一职责，可以轻松重构。 我从朋友那里听说过，它更方便（尽管对我来说这听起来太复杂了）。

我想知道当 Laravel 参与其中时，最流行的构建 RESTful 应用程序的方法是什么。我提到的还有其他方法吗？

【参考方案1】：

个人，

我喜欢将它们分开，因为这样更容易维护。是的，您必须跟踪 2 个不同的项目/文件夹/存储库，但它们是同一个蛋糕。

在 Laravel 中搭建 API 非常简单。我假设你已经知道如何做到这一点。你担心失去 Laravel Mix 提供的优势，但相信我，你并没有失去什么。

由于您的偏好是 Angular，因此只需克隆任何种子项目存储库并设置所有内容。例如： 1. AngularJS：https://github.com/angular/angular-seed 2.角2：https://github.com/mgechev/angular-seed

如您所见，这些种子项目已经拥有您需要的所有构建工具，现在事情似乎变得更容易了。这就是框架的用途。

现在假设稍后您想将移动应用添加到堆栈中。你甚至不需要改变任何东西。您的 API 已经独立于前端运行，反之亦然。

【参考方案2】：

问题是基于意见的......所以这是我的固执己见的答案。

TLDR：为了提高开发速度和可以说更令人满意，作为一个项目构建。不要过早地不必要地过度复杂化。当项目变得足够大，并开始为您带来一些收入时，请考虑拆分项目 - 您会知道什么时候是时候了。

Laravel 生态系统非常适合小型、中型甚至大型应用程序。

Laravel 为您提供了一个资源文件夹，您可以在其中放置所有 javascript 和前端资产。你有 Envoy 来部署你的应用程序并编写你的部署脚本。你有混合来建立你的资产。您不必使用 mix - 您可以编写自己的 gulp/webpack/grunt 等...

通过作为一个项目保持在一起，您可以将同一个 IDE 项目用于前端和后端工作，同时保持关注点分离，因为所有后端代码都与前端代码完全分离。您可以调整从 angular 发送的有效负载，并调整如何在 php api 中轻松轻松地处理有效负载，因此您只需要 1 个 ide 和一个浏览器和一个终端客户端。

将项目保持在一起的最大好处是，假设您使用的是 VCS (git)，而且您确实应该使用，那么您的前端和后端将始终彼此同步。否则，您需要管理和协调前端和后端代码的部署。

当您的应用程序变得足够大时，分离项目不会花费很长时间，因为前端和后端应该已经非常松散耦合了。

想想您为应用程序引入的所有复杂层。当您将更改部署到 REST API 时，您可能还需要将更改部署到 Angular 应用程序。哪个版本的 Angular 应用程序与哪个版本的 API 兼容？如果您有一个开发团队，从事特定项目，那么这种复杂性就会得到回报 - 但大多数团队都有适当的流程来管理、同步和自动化部署。

【讨论】：

不是真的基于意见的：拥有 2 个项目意味着拥有 2 套模型，这需要更多的维护。模型不需要不同（如果它们不同，这只会增加更多维护），所以这是不必要的重复。分离的问题通过使用不同的控制器来解决，这就是 MVC 的全部意义所在。使用 REST api，根本没有“V”部分（在后端）

【参考方案3】：

我认为你应该选择 2 个项目。我会的。

我将举一个使用复杂度增长率的例子。这只是根据我自己的经验。 （X 表示功能的数量，Y 表示实现的复杂程度）

对于单个项目，一开始非常简单。没有与服务器的通信，没有硬的东西，一切都是纠结的。然后接近尾声，创建更多功能/页面变得越来越难，因为一切都很纠结。

或者作为一个函数：

但是，如果您从 2 个项目开始，当然，一开始会更难（沟通、同步等），但复杂性的增长速度不会那么高。每一件事都有它自己的责任，每一件事都做它需要做的事情。测试更简单，扩展更简单，重构更简单，轻松完成项目。

或者作为一个函数：

显然，从上面的图表中，您可以推断出单个项目的增长速度要慢得多。 （当然，不是实际数字，我没有测量任何东西或跟踪此类项目，这只是出于我自己的经验）

【讨论】：

如果你把你的前端和后端项目代码分成两个独立的目录，它们之间的复杂性/耦合性在哪里？

@Gravy 前面依赖后面，后面决定了一切，并且几乎是独立的。每个项目本身都很复杂，但总复杂度不到 1 个项目