单个API端点的优缺点

Question

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

示例1 - 获取具有特定字段的用户（_join表示sql表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长度受限的数据长度，而请求正文则不受限制
• 要在网址中转义的特殊字符，这可能会导致网址长而不清晰

这些是赞成请求体中数据的2个优点，但我同意url中的数据更容易测试和使用，因为不需要像curl或postman这样的http客户端工具来验证你的端点。

但是，如果要完全实现REST，则REST具有更严格的约定：

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

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

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