单一API端点的优缺点

Question

我正在创建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是否更易于实现，更安全，更易于使用或缓存？

Answer 1

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

• URL长度限制了数据长度，而请求正文则没有限制
• 要在网址中转义的特殊字符，可能导致网址冗长且不清楚

这两个赞成在请求正文中使用数据的优点，但是我同意url中的数据更易于测试和使用，因为tou不需要curl或postman之类的http客户端工具即可验证您的端点。

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

• 使用正确的http请求（获取，发布，修补，删除和放置）在单个端点上实施Crud操作
• 返回正确的http代码
• 使用标准数据格式进行输入和输出（json或XML）

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

对于小型应用程序，我们可能会遵循一些快捷方式，但并没有完全遵守。到目前为止，我已经集成了几种服务，每次我都可以告诉您，没有一个实现标准的REST：-）