我正在创建 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的长度是有限制的，而request body没有限制
- url 中需要转义的特殊字符会导致 url 长且不清晰
这些是支持请求正文中数据的 2 个优点，但我同意 url 中的数据更易于测试和使用，因为您不需要像 curl 或 postman 这样的 http 客户端工具来验证您的端点。
然而，如果您想完全实现它，REST 有更严格的约定:
- 使用正确的 http 请求(get、post、patch、delete 和 put)在单个端点上实现 crud 操作
- 返回正确的 http 代码作为结果
- 使用标准数据格式进行输入和输出(json 或 XML)
为了在系统之间实现更好的互操作性，建议遵守 REST 和微服务设计模式。
对于小型应用程序，我们可以走一些捷径而不是完全遵守。到目前为止，我已经集成了多项服务，但每次我都可以告诉你，没有一项服务实现了标准 REST :-)
关于api - 单一 API 端点的优缺点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55651569/