单一 API 端点的优缺点

Question

我正在创建 API 并试图找出计划好的方法。
该 API 不是公开的，它将被我构建的 SPA 和移动应用程序使用。
所以我在考虑类似 GraphQL 的设计，但没有发布 json 和常规的 HTTP 方法。 对于 GET 方法，类似这样的事情：

示例 1 - 获取具有特定字段的用户（_join 表示 sql table join），排序和限制：
api.com?table=users&displayFields=id,name,email,address,tel,country_join&orderBy=asc&orderColumn=name&offset=0&limit=10

示例 2 - 基于所有字段、排序和限制的搜索参数获取用户：
api.com?table=users&search=John&searchFields=name,email&orderBy=asc&orderColumn=name&offset=0&limit=10

我认为这很糟糕，因为 REST 是标准的，否则我会看到更多这种方法的例子。
但为什么这很糟糕？ 对我来说，它似乎更容易开发和使用更灵活。
我提供的示例的适当 REST API 是否更易于实现、更安全、更易于使用或缓存？

Answer 1

我看到将变量放入 url 与请求正文之间的主要区别是：

• 数据的长度作为 url 长度是有限的，而请求体不是
• 要在 url 中转义的特殊字符，这可能导致 url 长而不清楚

这是支持请求正文中数据的 2 个优点，但我同意 url 中的数据更易于测试和使用，因为您不需要像 curl 或邮递员这样的 http 客户端工具来验证您的端点。

然而，如果你想完全实现它，REST 有更严格的约定：

• 使用正确的 http 请求（get、post、patch、delete 和 put）在单个端点上实现 crud 操作
• 结果返回正确的http代码
• 使用标准数据格式进行输入和输出（json 或 XML）

为了更好地实现系统之间的互操作性，建议遵守 REST 和微服务设计模式。

对于小型应用程序，我们可以遵循一些捷径而不完全遵守。 到目前为止，我已经集成了几个服务，每次我都可以告诉你，没有一个服务实现了标准的 REST :-)