我正在创建API，并试图弄清楚计划的方法有什么好处。
该 API 不是公开的，它将由我构建的 SPA 和移动应用程序使用。
所以我正在考虑类似 GraphQL 的设计，但没有发布 json 并使用常规的 HTTP 方法。 GET方法的类似内容：
示例 1 - 获取具有特定字段(_join表示 sql 表连接)、排序和限制的用户：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 是否更容易实现、更安全、更易于使用或缓存？
我看到将变量放在 url 中与请求正文之间的主要区别是：
- 作为 URL 长度的数据长度受到限制，而请求正文不受限制 URL
- 中要转义的特殊字符，这可能导致 URL 长且不清晰
这是支持请求正文中的数据的 2 个优点，但我同意 url 中的数据更容易测试和使用，因为 tou 不需要像 curl 或邮递员这样的 http 客户端工具来验证您的端点。
但是，如果您想完全实现 REST 的约定，则具有更严格的约定：
- 使用正确的 HTTP 请求(获取、发布、修补、删除和放置)在单个端点上实现 CRUD 操作
- 返回正确的 HTTP 代码作为结果
- 使用标准数据格式进行输入和输出(JSON 或 XML)
为了更好地实现系统之间的互操作性，建议遵守 REST 和微服务设计模式。
对于小型应用程序，我们可以遵循一些快捷方式并且不完全遵守。到目前为止，我已经集成了几个服务，每次我都可以告诉你，它们中没有一个实现标准的REST：-)