Golang 中的 RESTful 服务是否应该包含客户端接口？

Question

如果我在 Golang 中开发 Booking REST 服务（即包预订）。在允许业务操作的情况下创建 BookingClient 接口（由结构支持）是一种“GO 方式”，以便我的宁静服务的客户端将使用 BookingClient（从包预订导入）而不是直接发送 http 请求？

Answer 1

一般来说，不 - 如果您提供特定语言的客户端，那只会是一种方便，因此（某些）用户可以更轻松地使用您的 API。这当然假设您的客户端设计良好。我不会仅仅在 Go 中提供一个接口来指示一组可能的 API 调用。这将有利于非常狭窄的受众范围，可能对于那些自己为您的 API 开发客户端的人来说，使用恰好与您的服务器的实现相同的编程语言。即便如此，他们可能并不真正喜欢使用接口的想法（例如，他们可能只需要一组特定的方法）。如果你想为你的 API 提供一个客户端，继续做，但是将它与实际的服务器分开（不同的包，甚至可能是不同的 repo）。一般来说，人们通过 HTTP 开发 API 以允许广泛的客户端访问它，可以用任何语言编写。我不会提供一些接口，而是将时间花在编写好的文档上。在我看来，假设没有提供更多上下文，您的问题的答案应该没有什么不同，如果您问自己是否应该在 Python 中提供客户端。但是，例如，如果您的 API 由您的公司内部使用并且您主要使用 Go 进行开发，那么整个情况可能会发生变化。

Answer 2

测试在 Go 中很重要，所以编写可测试的代码是你应该做的事情。如果您使用直接 http 请求，与使用模拟结构相比，您将更难编写单元测试。是否有任何理由使用 aClient而不是调用调用 REST 端点的函数？模拟一个更大的东西通常更难，比如一个 Client 结构，而不是一组小函数。您应该将客户booking.Client置于 避免重复自己 ( booking.BookingClient) 并可能重命名Client为更具描述性的名称。

Answer 3

通常最好这样做，大多数公司都这样做，但提供直接使用 API 的文档。主要用例是人们使用与您想要的语言不同的语言。你可以看看我写的一个新的 RESTful 框架，它包括使用 Go 模板自动编译客户端的基础设施，尽管我还没有编写 Go 客户端编译器。如果你想写一个，将不胜感激:) https://github.com/EverythingMe/vertex