API与REST类似,但也使用GraphQL之类的变体?

时间:2019-07-16 02:25:27

标签: rest api graphql rpc

设计API使其像REST一样会存在巨大的缺陷,因为存在资源的GET端点(即/ courses,/ professors,/ students),但是所有POST / PUT / DELETE都使用单个端点(即/ actions)和有效负载,该有效负载指定了应如何处理请求以及处理请求所需的必要信息(即{action_name =“ create_course”,name =“ math”}或{action_name =“ drop_course”,course_id = 5}。

1 个答案:

答案 0 :(得分:3)

  

会存在巨大缺陷

缓存。

缓存是REST architectural style中的重要元素; “大颗粒超媒体数据”希望被缓存,这样您就不会再次通过网络反复发送相同的数据。在HTTP中,我们有一个专用于caching semantics的RFC。这包括缓存失效-如果有成功的不安全请求,通用的http感知组件将知道使缓存条目失效。

因此,通过将所有不安全的请求路由到单个端点,通用组件最终将缓存无效化应用于操作端点,而不是应用于请求实际更改的任何资源。

DELETE还有一个缺陷-它不需要有效载荷

  

DELETE请求消息中的有效负载没有定义的语义;在DELETE请求上发送有效内容正文可能会导致某些现有实现拒绝该请求。

因此,参与消息交换的任何通用组件都将假设/actions端点已被删除,而不是有效负载所引用的某些任意资源。

PUT的问题有所不同

  

PUT方法请求创建目标资源的状态或将其替换为由请求消息有效负载中包含的表示形式定义的状态。

因此,在您的情况下,通用组件将假设您的消息实际上是/actions资源的建议表示形式。

统一接口的意义在于,每个人都同意语义,并且您可以从不了解您的特定域的通用HTTP感知库中提取值。当您开始对语义进行愚弄时,您对可能发生的任何财产损失承担责任。

远程创作语义(PUT / PATCH / DELETE)确实不适用于单个/actions端点。

POST的效果要好一些,因为约束很小。在某种程度上,将所有内容发布到单个端点可以将HTTP从应用程序协议减少到传输协议。

请注意,GraphQL及其之前的SOAP接受了这种权衡。马匹。

  

什么是“通用HTTP组件”?

浏览器,缓存,代理,服务器,搜寻器...。任何有权访问正在交换的消息的人,但不能访问域的带外细节。

  

通过对成功的不安全请求进行缓存无效化,您是否还意味着如果跟踪配方,则将对/ recipes的GET进行缓存,直到出现对/ recipes的GET / PUT / PATCH / DELETE请求?

对GET对/recipes的响应可能会被缓存,直到对/recipes进行POST / PUT / PATCH / DELETE为止。

是否 是否要缓存取决于响应随附的缓存头的语义。

当然,我的本地缓存不会知道您发出的请求,因此我可能正在查看过时的副本。不过,我将为自己的更改获得“读自己的写”语义。

更有趣的情况是服务器前面的反向代理,这将在成功提出不安全的请求后使它的缓存条目无效,从而减少了服务器的负载,同时仍在提供新数据。