laravel - 使用 Laravel 进行 API 版本控制和身份验证

Question

我正在使用 Laravel 框架构建服务。我将生成一个 API 供 Android 和 iOS 应用程序使用。同时，我将进行内部 API 调用以更新我的 HTML/Blade View (或在将来更新我的 SPA 前端)。所有 3 个客户端(web、Android、iOS)都将由我们的团队开发，因此沟通很可能会很容易!

我搜索了很多，似乎在 API 版本控制方面有不同的方法(Best practices for API versioning? 或 https://apisyouwonthate.com/blog/api-versioning-has-no-right-way)。 我的问题与其他问题的区别在于 API 的访问方式和访问者。我的 API 将被我们自己的应用程序(网络或移动)简单地使用。对我们 API 的调用将由我们自己的应用程序生成。任何第三方应用都不会访问此 API。

我有几个问题:

1. 在这种情况下，API 版本控制的正确方法是什么？将使用 API 的开发人员将在同一个办公室，因此每次我们对 API 进行重大更改时都会进行应用程序更新。
   • URI 版本控制
     • https://example.com/api/v1/users
     • https://api-v1.example.com/users (作为子域)
   • 资源版本控制(基于 MIME)
     • 接受:application/vnd.example.v1+json
2. 使用子域作为 API 版本控制有好处吗？从财务上讲，如果我们使用 SSL，那么我们还需要购买通配符 SSL 来容纳子域，所以在我看来，情况更糟。
3. 在决定我们将遵循的 API 版本控制路径之后，我们需要选择我们的用户将如何通过我们的 API 进行身份验证。使用 Laravel，您可以使用 token、JWT、Passport 等对 API 进行身份验证。我很确定我的服务不会被其他服务用于身份验证，但这是否会从我的选择中删除 Passport？考虑到这一点来实现 Passport 是否有点矫枉过正？

提前致谢!

Answer 1

url 版本是必需的，因为例如，google play 不允许强制更新，因此会有不同版本的 android 客户端同时工作。我创建了一个简单的包来帮助 URL 版本控制和回退。 https://github.com/mbpcoder/laravel-api-versioning

对于资源版本控制，Laravel 有一个生成响应的资源对象最好为每个 API 版本创建一个文件夹。

如果对 API 的更改更深，例如您需要更改数据库结构，那么我通常会转到旧 API 并更新它们的 Controller 、模型……以满足新结构。