API设计,从RPC、SOAP、REST到GraphQL(四)
Comments
tags:技术
前两篇: (一)前言&RPC (二)SOAP (三)REST (四)GraphQL(Next?) Talk is cheap. Show me the code. 先放个GraphQL的代码,在这里。(竟然是一个月前的代码了,写文章还是不能拖拉啊) 如同上一篇文章所说,REST是现在API设计的绝对主流思想,但也不是没有缺点的。比如太多的HTTP请求,抓取了过多的信息等。当然,现在有好多各种各样的框架、协议尝试对REST做一些改进。比如HAL、Swagger、OData JSON API。(以上几个都可以花时间浏览下,还是很有启发的) 还有很多小的工程或者项目的内部工具都是为了更加爽快的使用REST而诞生的。我不想一一列举这些工具,这里只是从设计角度,假设我们自己要设计一个基于REST的改进工具,我们会对这个工具有那些要求: 1.最小化HTTP请求数量 每个HTTP请求都是有代价的,握手、延迟、解析甚至如果在移动平台上过多HTTP请求对手机电池的消耗都是必须考虑的。理想情况下,…
API设计,从RPC、SOAP、REST到GraphQL(三)
Comments
tags:技术
前两篇: (一)前言&RPC (二)SOAP (三)REST(now) 接下来,在RPC和SOAP之后,我们迎来了REST。 REST(Representational State Transfer),实际上一般指的是RESTful的架构风格,是由Roy Fielding在2000年的这篇著名论文里提出的。 那REST到底对API设计做了什么改进呢?先来回顾一下前面两篇文章里介绍的RPC和SOAP,RPC类似于系统和系统之间讲黑话,SOAP改进了RPC,使之有了统一“普通话”。但是“普通话”是不是最优解呢?我们来看一个调用远程系统创建用户时可能遇到的接口名: createUser() //很平常的命名 insertUser() //也可以接受 chuangjianyonghu() //别说你没看到过 chuangjianUser() //土洋结合 cjyh() //中文拼音首字母缩写 api123321() //恩,保密工作做的不错? 根本就有无穷种可能性好伐?那么,我们能不能有一个接口的规范?比如,对于任何系统,暴露出来的创建用户一定是createUser?REST以一种革命性的抽象,…
API设计,从RPC、SOAP、REST到GraphQL(二)
Comments
tags:技术
SOAP is what most people would consider a moderate success. -- Don Box <A Brief History of SOAP> 上一篇:前言&RPC (二)SOAP(90s) RPC之后的下一个主流API设计风潮就是SOAP了。 SOAP(Simple Object Access Protocol)由Dave Winer, Don Box, Bob Atkinson, 和 Mohsen Al-Ghosein 在1998年为微软所设计。 这几个设计人员敏锐的观察到了RPC的最大缺陷:没有统一标准。使用RPC就好比发明团伙内部的黑话一样,更精简、更加保密、更加可定制,坏处就是要求双方(sender,…
API设计,从RPC、SOAP、REST到GraphQL(一)
Comments
tags:技术
"There is no such thing as a new idea. It is impossible. We simply take a lot of old ideas and put them into a sort of mental kaleidoscope." -- 马克·吐温 <马克·吐温自传> 我自己的几个工具(@jinyexin/core, @jinyexin/corecli, @jinyexin/wechat)是基于REST设计的,在定义应该由框架自动生成哪些REST接口的时候,总是感觉到有很多痛点(下文谈到REST的时候会讲)。于是GraphQL进入了我的视线。 为了比较各种API设计的优劣,我想先回顾下历史上各个时代的API设计理念,从而理解为什么我们需要“…
一个简单的用TS实现的DI
Comments
tags:NodeJS, 技术, TypeScript
把原先项目里自己顺手实现的简单DI抽了出来 https://github.com/enixjin/simpleDependencyInjection…