hantsy

@lshero 类似方案，Okta

MS 的可以吧

东施效颦

@bestwaytowait GraphQL 可以解决一部分 REST 上的缺陷问题。

从某些角度，我感觉 GraphQL 是弥补了 REST 返回数据颗粒控制上问题。以前我一些做法是尽可能让 REST API 足够细， 返回数据足够细，结果面临的问题是，要么前端一个页面往往要调用多次聚合数据显示 （当然这和国内的前端水平也有很大关系，如果按 React 的 Presenter/Container 模式，页面可以组件切得足够细，逻辑和展示完全可以分离，而我看到的代码很多一个页面对应一个巨无霸组件解决），要么另外在服务器加一个 Gateway 去按需求聚合数据。

如果按 REST 思维去度量 GraphQL，GraphQL 完全违背了 REST 。一句话，GraphQL 不是 REST，而是为 API 开发提供了另外一种选择。

我的例子中，https://github.com/hantsy/spring-reactive-jwt-sample/blob/master/src/main/java/com/example/demo/domain/Post.java

也有 DRAFT，PUBLISHED 两个状态，这能跟 Http Status 扯上关系。

这种思维闻所未闻。今天算是开一个眼界了，Fielding 原来这么不受待见，还不如 V 站一个小喷壶，英文都看不懂的情况非要说他说的资源是文件。

还有之前看到一个什么 Redis 事务，同类。牛的病，能够扯到猪身上去了。

一个订单 10，8 种状态，订单 Oderstatus 只是数据属性 ，只要这个订单存在，返回订单，就可以进去。这东西能和 http status 能扯到一起，我只能服了你。

以前我很难理解，V 站那么多人说查询就会想 SQL 怎么写，你这思维大概知道了。