惠州市seo网站设计江苏省住房和城乡建设厅政务网站

当前位置： 首页 > news >正文

惠州市seo网站设计,江苏省住房和城乡建设厅政务网站,wordpress 分类目录调用,定制网站为什么贵前言 这章挺难的#xff0c;感觉离我比较远#xff0c;不太好懂#xff0c;简单记录吧。 这章主要讲访问远程服务#xff0c;主要对比了RPC和REST的区别#xff0c;可以结合知乎上的文章《既然有 HTTP 请求#xff0c;为什么还要用 RPC 调用#xff1f;》 这篇文章进行…前言 这章挺难的感觉离我比较远不太好懂简单记录吧。 这章主要讲访问远程服务主要对比了RPC和REST的区别可以结合知乎上的文章《既然有 HTTP 请求为什么还要用 RPC 调用》 这篇文章进行理解。 而对于远程服务调用它的内容不单单只有REST、RPC还有像SOAPWebSocketGraphQL等等之后我会写文章进行具体说明。 总结 1看完这章最大的一个问题REST和RPC到底有什么区别 首先REST是基于HTTP的我们这个问题可以先转换成HTTP和RPC的区别 HTTP和RPC同一级别还是被RPC包含答案是都可能。可以看下面这张图如果你说的HTTP是HTTP通信协议那么显然RPC是“包含”HTTP的因为RPC指的是远程调用是一个完整的远程调用方案它包括了接口规范序列化反序列化规范通信协议等。也就是只要是远程调用都可以叫RPCRPC可以基于HTTP这种通信协议实现比如gRPC也可以基于其它的。 如果你说的HTTP是指基于HTTP的远程调用方案包含了接口规范RESTful、序列化反序列化JSON等那它是与RPC同级的。举个例子Thrift一种RPC架构和基于HTTP的远程调用方案比较在这种情况下两者相互比较就成了Thrift通信协议和HTTP通信协议比较Binaryprotocal序列化方案和JSON序列化方案比较等。 在说回REST和RPC到底有什么区别 通过上面的解释REST和RPC可以说都是一种规范、方案或者风格只不过REST是基于HTTP远程调用方案的而RPC是比较自由的定制化程度比较高的。这也解释了为什么作者要将这两者并列在一起写。 2文章内容总结 在解决远程服务调用时第一个问题是进程间如何通信方法有利用管道、信号、信号量、消息队列、共享内存以及套接字借口各有利弊、适用场景其中最后一个适合同机器之间的进程通信。但是RPC远程调用远远比IPC进程间通信复杂很多会有很多问题像是网络并不可靠、存在延迟、安全问题等不能简单的把远程通信类比为IPC。 在RPC中会面临3个基本的问题如何表示数据序列化和反序列化、如何传递数据要考虑异常、超时、安全等、如何表示方法。基于此发展的RPC面临新的问题简单、普适、高性能这三点非常难以满足比如功能如果多起来协议就会变复杂效率会受影响要简单易用那很多事情必须遵循约定而不是配置才行要重视效率那就需要采用二进制的序列化器和较底层的传输协议支持的语言范围容易受限。所以在RPC的选择上决定了获得一些利益的同时要付出另外一些代价。最近几年RPC框架朝着更高层次不仅仅负责调用远程服务还管理远程服务与插件化方向发展的趋势不再追求独立地解决RPC的全部三个问题而是将一部分功能设计成“插件”让用户自己去选择。 对于RESTREST与RPC在思想上差异的核心是抽象的目标不一样即面向资源的编程思想与面向过程的编程思想。REST最主要的风格特点其实就是无状态接口抽象。可以用RMM模型分为3级来衡量服务的设计多么REST。 它优点有接口面向资源具有层次结构更易理解完全基于HTTP简化调用复杂度标准化并且实现广泛任何语言都实现都有HTTP接口不同程序交互非常如果是RPC自己还得重新实现。 缺点也很多像不适合应用于要求高性能传输的场景中REST与HTTP完全绑定在特定的场景中无法使用适合的传输协议、序列化方式等没有传输可靠性支持无法知道对方是否收到信息只能利用HTTP的幂等性进行重发REST缺乏对资源进行“部分”和“批量”的处理能力也就是面向资源并不非常的细粒度要拿一个资源可能会多拿无法批量是因为多次重复HTTP请求会报错只能自己控制请求频率。 正文 1 远程服务调用 1.1 进程间通信 远程服务调用Remote Procedure Call也就是我们经常听说的RPC。RPC出现的最初目的就是为了让计算机能够与调用本地方法一样去调用远程方法。 在同一进程内的通信以Java为例进程内的通信主要通过栈内存通过压进去里面的地址或事其他来进行消息传递。如果是不同进程之间则无法利用这个。 解决进程之间如何交换数据的问题起初我一直不知道进程间通信到底是要传递什么其实就是各种各样的数据被称为“进程间通信”Inter-Process CommunicationIPC有以下几种方式 管道Pipe可通过管道在进程间传递少量的信息。普通管道只用于有亲缘关系进程由一个进程启动的另外一个进程间的通信具名管道摆脱了普通管道没有名字的限制可以允许无亲缘关系进程间的通信。管道典型的应用就是命令行中的|操作符譬如ps -ef | grep javaps与grep都有独立的进程以上命令就通过管道操作符|将ps命令的标准输出连接到grep命令的标准输入上ps -ef命令用于显示当前系统中所有进程的详细信息包括进程 ID、用户、CPU 占用率等而grep java则用于过滤出包含“java”关键字的进程 。信号Signal信号用于通知目标进程有某种事件发生除了用于进程间通信外进程还可以发送信号给进程自身。信号的典型应用是kill命令譬如kill -9 pid用于强制终止指定进程。kill命令用于发送信号给指定的进程或进程组而-9则表示发送SIGKILL信号。信号量Semaphore信号量用于两个进程之间同步协作手段它相当于操作系统提供的一个特殊变量。// 伪代码示例 // 定义信号量 semaphore S 1; // 初始值为1,表示只有一个进程可以访问共享资源// P1进程 P(S); // P1等待信号量可用 // 访问共享资源R1 V(S); // P1释放信号量让其他进程可以访问共享资源// P2进程 P(S); // P2等待信号量可用 // 访问共享资源R1 V(S); // P2释放信号量让其他进程可以访问共享资源消息队列Message Memory以上三种方式只适合传递传递少量信息进程可以利用消息队列向队列添加消息被赋予读权限的进程则可以从队列消费消息。消息队列克服了信号承载信息量少管道只能用于无格式字节流以及缓冲区大小受限等缺点但实时性相对受限。共享内存Shared Memory允许多个进程访问同一块公共的内存空间这是效率最高的进程间通信形式。当一块内存被多进程共享时各个进程往往会与其它通信机制譬如信号量结合使用来达到进程间同步及互斥的协调操作。本地套接字借口IPC Socket消息队列和共享内存只适合单机多进程间的通信套接字接口是更为普适的进程间通信机制可用于不同机器之间的进程通信。出于效率考虑当仅限于本机进程间通信时套接字接口是被优化过的不会经过网络协议栈不需要打包拆包、计算校验和、维护序号和应答等操作只是简单地将应用层数据从一个进程拷贝到另一个进程。 1.2 通信的成本 之所以花费那么多篇幅来介绍IPC的手段是因为最初计算机科学家们的想法就是将RPC作为IPC的一种特例来看待的这个观点在今天仅分类上这么说也仍然合理只是到具体操作手段上不会这么做了。 对于最后一个本地套接字借口这样做的好处是由于Socket是网络栈的统一接口它也理所当然地能支持基于网络的跨机器的进程间通信。此外由于Socket是各个操作系统都有提供的标准接口完全有可能把远程方法调用的通信细节隐藏在操作系统底层从应用层面上看来可以做到远程调用与本地的进程间通信在编码上完全一致。这种透明的调用形式造成了程序员误以为通信是无成本的假象因而被滥用以致于显著降低了分布式系统的性能。 本地调用与远程调用当做一样处理这是犯了方向性的错误把系统间的调用做成透明反而会增加程序员工作的复杂度。比如两个进程通信谁作为服务端谁作为客户端怎样进行异常处理服务端出现多线程竞争怎么办等等问题。如果想要远程调用透明化需要为以下罪过买单反话1网络是可靠的2延迟是不存在的3带宽是无限的4网络是安全的5拓扑结构是一成不变的6总会有一个管理员7不必考虑传输成本8网络都是同质化的。 所以RPC应该是一种高层次的或者说语言层次的特征而不是像IPC那样是低层次的或者说系统层次的。 1.3 三个基本问题 虽然有很多RPC协议但都不外乎变着花样使用各种手段来解决一下三个基本问题 如何表示数据 这里数据包括了传递给方法的参数以及方法执行后的返回值。远程方法调用可能面临交互双方各自使用不同程序语言的情况即使只支持一种程序语言的RPC协议在不同硬件指令集、不同操作系统下同样的数据类型也完全可能有不一样表现细节譬如数据宽度、字节序的差异等等有效的做法是将交互双方所涉及的数据转换为某种事先约定好的中立数据流格式来进行传输。这个过程其实就是我们常听的序列化和反序列化。如何传递数据 准确地说是指如何通过网络在两个服务的Endpoint之间相互操作、交换数据。这里“交换数据”通常指的是应用层协议实际传输一般是基于标准的TCP、UDP等标准的传输层协议来完成的。两个服务交互不是只扔个序列化数据流来表示参数和结果就行的许多在此之外信息譬如异常、超时、安全、认证、授权、事务等等都可能产生双方需要交换信息的需求。如何表示方法 这在本地方法调用中并不是太大的问题编译器或者解释器会根据语言规范将调用的方法签名转换为进程空间中子过程入口位置的指针。而对于不同的语言每种语言的签名都可能不同所以需要一个跨语言的统一的标准才行。这个标准做起来可以非常简单譬如直接给程序的每个方法都规定一个唯一的、在任何机器上都绝不重复的编号调用时压根不管它什么方法签名是如何定义的直接传这个编号就能找到对应的方法。这是最简单的方式还有些比较高级的方式。 1.4 统一的RPC 那些面向透明的、简单的RPC协议要么依赖于操作系统要么依赖于特定语言总有一些先天约束那些面向通用的、普适的RPC协议无法逃过使用复杂性的困扰而那些意图通过技术手段来屏蔽复杂性的RPC协议又不免受到性能问题的束缚。简单、普适、高性能这三点似乎真的难以同时满足。 1.5 分裂的RPC 由于一直没有一个同时满足以上三点的“完美 RPC 协议”出现所以远程服务器调用这领域里逐渐进入了群雄混战的时代距离“统一”是越来越远并一直延续至今。现在已经相继出现过 RMISun/Oracle、ThriftFacebook/Apache、Dubbo阿里巴巴/Apache、gRPCGoogle、Motan1/2新浪、FinagleTwitter、brpc百度/Apache、.NET Remoting微软、ArvoHadoop、JSON-RPC 2.0JSON-RPC工作组等等。这些RPC功能、特点不尽相同有的是某种语言私有有的能支持跨越多门语言有的运行在应用层HTTP协议之上有的能直接运行于传输层TCP/UDP协议之上但肯定不存在哪一款是“最完美的RPC”。今时今日任何一款具有生命力的RPC框架都不再去追求大而全的“完美”而是有自己的针对性特点作为主要的发展方向朝着面向对象发展朝着性能发展朝着简化发展等等。 经历了 RPC 框架的战国时代开发者们终于认可了不同的 RPC 框架所提供的特性或多或少是有矛盾的很难有某一种框架说“我全部都要”。要把面向对象那套全搬过来就注定不会太简单功能多起来协议就要弄得复杂效率一般就会受影响要简单易用那很多事情就必须遵循约定而不是配置才行要重视效率那就需要采用二进制的序列化器和较底层的传输协议支持的语言范围容易受限。决定了选择框架时在获得一些利益的同时要付出另外一些代价。 最近几年RPC框架有明显的朝着更高层次不仅仅负责调用远程服务还管理远程服务与插件化方向发展的趋势不再追求独立地解决RPC的全部三个问题而是将一部分功能设计成扩展点让用户自己去选择。框架聚焦于提供核心的、更高层次的能力譬如提供负载均衡、服务注册、可观察性等方面的支持。这一类框架的代表有Facebook的Thrift与阿里的Dubbo。比如Dubbo它默认有自己的传输协议Dubbo协议同时也支持其他协议默认采用Hessian 2作为序列化器如果你有JSON的需求可以替换为 Fastjson如果你对性能有更高的追求可以替换为Kryo (opens new window)等效率更好的序列化器。这种设计在一定程度上缓和了RPC框架必须取舍难以完美的缺憾。 2 REST设计风格 REST与RPC在思想上差异的核心是抽象的目标不一样即面向资源的编程思想与面向过程的编程思想两者之间的区别。 而概念上的不同是指REST并不是一种远程服务调用协议它就不是一种协议。协议都带有一定的规范性和强制性它只有一些指导原则但并不受强制的约束所以REST只能说是风格并且能完全达到REST所有指导原则的系统也是不多见的。 至于使用范围REST与RPC作为主流的两种远程调用方式在使用上是确有重合的但重合的区域有多大就见仁见智了。上一节提到了当前的RPC协议框架都各有侧重点并且列举了RPC一些发展方向如分布式对象、提升调用效率、简化调用复杂性等等。这里面分布式对象这一条线的应用与REST可以说是毫无关联而能够重视远程服务调用效率的应用场景就基本上已经排除了REST应用得最多的供浏览器端消费的远程服务因为以浏览器作为前端对于传输协议、序列化器这两点都不会有什么选择的权力哪怕想要更高效率也有心无力而在移动端、桌面端或者分布式服务端的节点之间通讯这一块REST虽然照样有宽阔的用武之地只要支持HTTP就可以用于任何语言之间的交互不过通常都会以网络没有成为性能瓶颈为使用前提在需要追求传输效率的场景里REST提升传输效率的潜力有限对追求简化调用的场景——前面提到的浏览器端就属于这一类的典型众多 RPC 里也就JSON-RPC有机会与REST竞争其他RPC协议与框架但很少见有实际项目把它们真的用到浏览器上的。 2.1 理解 REST REST的英文是REpresentational State Transfer表征状态转移。 资源Resource 其实就是数据。表征Representation 浏览器向服务端发出请求“我需要这个资源的HTML格式”服务端向浏览器返回的这个HTML就被称之为“表征”。状态State 比如说当你读完了一篇文章想看后面是什么内容时你向服务器发出请求“给我下一篇文章”。但是“下一篇”是个相对概念必须依赖“当前你正在阅读的文章是哪一篇”才能正确回应这类在特定语境中才能产生的上下文信息即被称为“状态”。转移Transfer 服务器通过某种方式把“用户当前阅读的文章”转变成“下一篇文章”这就被称为“表征状态转移”。 2.2 RESTful的系统 以下为满足REST风格的六大原则 客户端与服务端分离 将用户界面所关注的逻辑和数据存储所关注的逻辑分离开来有助于提高用户界面的跨平台的可移植性。无状态 每一次从客户端发送的请求中应包括所有的必要的上下文信息会话信息由客户端负责保存维护服务端依据客户端传递的状态来执行业务处理逻辑。客户端承担状态维护职责以后会产生一些新的问题譬如身份认证、授权等可信问题它们都应有针对性的解决方案。 但必须承认的现状是目前大多数的系统都达不到这个要求往往越复杂、越大型的系统越是如此。服务端无状态可以在分布式计算中获得非常高价值的好处但大型系统的上下文状态数量完全可能膨胀到让客户端在每次请求时提供变得不切实际的程度在服务端的内存、会话、数据库或者缓存等地方持有一定的状态成为一种主流的方案。可缓存 使用无状态的设计则可能会需要多次请求或者在请求中带有额外冗余的信息。为了缓解这个矛盾REST将部分服务端的应答缓存起来。运作良好的缓存机制可以减少客户端、服务器之间的交互甚至有些场景中可以完全避免交互这进一步提高了性能。分层系统 这里所指的并不是表示层、服务层、持久层这种意义上的分层。而是指客户端一般不需要知道是否直接连接到了最终的服务器抑或连接到路径上的中间服务器。中间服务器可以通过负载均衡和共享缓存的机制提高系统的可扩展性这样也便于缓存、伸缩和安全策略的部署。该原则的典型的应用是内容分发网络Content Distribution NetworkCDN。比如你访问Github你所发出的请求一般假设你在中国国境内的话并不是直接访问位于GitHub的源服务器而是访问了位于国内的CDN服务器但作为用户你完全不需要感知到这一点。统一接口 REST希望开发者面向资源编程希望软件系统设计的重点放在抽象系统该有哪些资源上而不是抽象系统该有哪些行为上。 面向资源编程的抽象程度通常更高。抽象程度高意味着坏处是往往距离人类的思维方式更远而好处是往往通用程度会更好。按需代码 REST的基本思想是面向资源来抽象问题它与此前流行的编程思想——面向过程的编程在抽象主体上有本质的差别。在REST提出以前人们设计分布式系统服务的唯一方案就只有RPCRPC是将本地的方法调用思路迁移到远程方法调用上开发者是围绕着“远程方法”去设计两个系统间交互的。这样做的坏处不仅是“如何在异构系统间表示一个方法”、“如何获得接口能够提供的方法清单”都成了需要专门协议去解决的问题RPC 的三大基本问题更在于服务的每个方法都是完全独立的服务使用者必须逐个学习才能正确地使用它们。Google 在《Google API Design Guide 》中曾经写下这样一段话“以前人们面向方法去设计RPC API譬如CORBA和DCOM随着时间推移接口与方法越来越多却又各不相同开发人员必须了解每一个方法才能正确使用它们这样既耗时又容易出错。”以下为REST的好处 降低的服务接口的学习成本。统一接口是REST的重要标志将对资源的标准操作都映射到了标准的HTTP方法上去这些方法对于每个资源的用法都是一致的语义都是类似的不需要刻意去学习。资源天然具有集合与层次结构。举个具体例子一个商城用户中心的接口设计“GET /users/icyfenix/cart/2”用户资源会拥有多个不同的下级的资源譬如若干条短消息资源、一份用户资料资源购物车中又会有自己的下级资源譬如多本书籍资源。很容易在程序接口中构造出这些资源的集合关系与层次关系而且是符合人们长期在单机或网络环境中管理数据的直觉的。REST绑定于HTTP协议。这是缺点也是优点。因为HTTP本来就是面向资源而设计的网络协议带来的好处是对于二进制细节、编码形式、报文格式、连接方式等细节不需要考虑REST将复用HTTP协议中已经定义的概念和相关基础支持来解决问题。而坏处自然是当你想去考虑那些HTTP不提供的特性时便会彻底地束手无策。 2.3 RMM成熟度 RMM 成熟度一个衡量“服务有多么REST”的模型。简单来说 第0级完全不REST。 类似RPC也就是面向过程比如要得到一个时间段内医生的空闲时间 POST /appointmentService?actionquery HTTP/1.1 {date: 2020-03-04, doctor: mjones}第1级开始引入资源的概念。 依然是得到一个时间段内医生的空闲时间和预约这里的问题一是只处理了查询和预约如果我临时想换个时间要调整预约或者我的病忽然好了想删除预约这都需要提供新的服务接口。二是处理结果响应时只能靠着结果中的code、message这些字段做分支判断每一套服务都要设计可能发生错误的code这很难考虑全面而且也不利于对某些通用的错误做统一处理三是并没有考虑认证授权等安全方面的内容譬如要求只有登陆用户才允许查询医生档期时间。 POST /doctors/mjones HTTP/1.1 {date: 2020-03-04}POST /schedules/1234 HTTP/1.1 {name: icyfenix, age: 30, ……}第2级引入统一接口映射到 HTTP 协议的方法上。 解决了第一级留下的三个问题REST的做法是把不同业务需求抽象为对资源的增加、修改、删除等操作来解决第一个问题使用HTTP协议的Status Code这里应该是指403、200这些已经定义好的而不像第1级的code是自己定义的可以涵盖大多数资源操作可能出现的异常而且Status Code可以自定义扩展以此解决第二个问题依靠HTTP Header中携带的额外认证、授权信息来解决第三个问题。 第3级超媒体控制在本文里面的说法是“超文本驱动”。 第2级是目前绝大多数系统所到达的REST级别但仍不是完美的至少还存在一个问题你是如何知道预约mjones医生的档期是需要访问/schedules/1234这个服务Endpoint的“超文本驱动”所希望的是除了第一个请求是有你在浏览器地址栏输入所驱动之外其他的请求都应该能够自己描述清楚后续可能发生的状态转移由超文本自身来驱动。所以当你输入了查询的指令之后 GET /doctors/mjones/schedule?date2020-03-04statusopen HTTP/1.1HTTP/1.1 200 OK{schedules[{id: 1234, start:14:00, end: 14:50, doctor: mjones,links: [{rel: comfirm schedule, href: /schedules/1234}]},{id: 5678, start:16:00, end: 16:50, doctor: mjones,links: [{rel: comfirm schedule, href: /schedules/5678}]}],links: [{rel: doctor info, href: /doctors/mjones/info}] }如果做到了第3级REST那服务端的API和客户端也是完全解耦的你要调整服务数量或者同一个服务做API升级将会变得非常简单。
2.4 不足与争议 面向资源的编程思想只适合做CRUD面向过程、面向对象编程才能处理真正复杂的业务逻辑 并不是。HTTP 的四个最基础的命令POST、GET、PUT 和 DELETE很容易让人直接联想到CRUD操作它们涵盖了信息在客户端与服务端之间如何流动的几种主要方式。而针对一些比较抽象的场景如果真不好把HTTP方法映射为资源的所需操作REST也并非刻板的教条用户是可以使用自定义方法的按Google推荐的REST API风格自定义方法应该放在资源路径末尾嵌入冒号加自定义动词的后缀。譬如可以把删除操作映射到标准DELETE方法上如果此外还要提供一个恢复删除的API那它可能会被设计为“POST /user/user_id/cart/book_id:undelete”。如果你不想使用自定义方法那就设计一个回收站的资源在那里保留着还能被恢复的商品将恢复删除视为对该资源某个状态值的修改映射到PUT或者PATCH方法上这也是一种完全可行的设计。 面向资源的编程思想与另外两种主流编程思想只是抽象问题时所处的立场不同只有选择问题没有高下之分 1面向过程编程时为什么要以算法和处理过程为中心输入数据输出结果当然是为了符合计算机世界中主流的交互方式。 2面向对象编程时为什么要将数据和行为统一起来、封装成对象当然是为了符合现实世界的主流的交互方式。 3面向资源编程时为什么要将资源作为抽象的主体把行为看作是统一的接口当然是为了符合网络世界的主流的交互方式。 REST与HTTP完全绑定不适合应用于要求高性能传输的场景中 作者很大程度上赞同此观点但并不认为这是REST的缺陷HTTP并不是传输层协议它是应用层协议如果仅将HTTP当作传输的全部是不恰当的。对于需要直接控制传输如二进制细节、编码形式、报文格式、连接方式等细节的场景中REST确实不合适。 REST不利于事务支持 如果“事务”指的是数据库那种的狭义的刚性ACID事务那除非完全不持有状态否则分布式系统本身与此就是有矛盾的CAP 不可兼得这是分布式的问题而不是REST的问题。如果“事务”是指通过服务协议或架构在分布式服务中获得对多个数据同时提交的统一协调能力2PC/3PC这 REST 确实不支持。如果“事务”只是指希望保障数据的最终一致性说明你已经放弃刚性事务了这才是分布式系统中的正常交互方式使用REST肯定不会有什么阻碍谈不上“不利于”。当然对此REST也并没有什么帮助这完全取决于你系统的事务设计。 REST没有传输可靠性支持 是的并没有。在HTTP中你发送出去一个请求通常会收到一个与之相对的响应譬如HTTP/1.1 200 OK 或者 HTTP/1.1 404 Not Found诸如此类的。但如果你没有收到任何响应那就无法确定消息到底是没有发送出去抑或是没有从服务端返回回来这其中的关键差别是服务端到底是否被触发了某些处理应对传输可靠性最简单粗暴的做法是把消息再重发一遍。这种简单处理能够成立的前提是服务应具有幂等性即服务被重复执行多次的效果与执行一次是相等的。HTTP也协议要求GET、PUT和DELETE应具有幂等性。 REST缺乏对资源进行“部分”和“批量”的处理能力 这个观点作者是认同的这很可能是未来面向资源的思想和API设计风格的发展方向。譬如你仅仅想获得某个用户的姓名RPC风格中可以设计一个“getUsernameById”的服务返回一个字符串尽管这种服务的通用性实在称不上“设计”二字但确实可以工作而REST风格中你将向服务端请求整个用户对象然后丢弃掉返回的结果中该用户除用户名外的其他属性这便是一种“过度获取”你准备把某个用户的名字增加一个“VIP”前缀提交一个PUT请求修改这个用户的名称即可而你要给1000个用户加VIP时如果真的去调用1000次PUT浏览器会回应你HTTP/1.1 429 Too Many Requests此时你就不得不先创建一个任务资源把1000个用户的ID交给这个任务控制请求的频率避免因为请求过于频繁而被服务器拒绝。
目前一种理论上较优秀的可以解决以上这几类问题的方案是GraphQL这是由Facebook提出的一种面向资源API的数据查询语言如同SQL一样挂了个“查询语言”的名字但其实CRUD都有涉猎。比起依赖HTTP无协议的RESTGraphQL可以说是另一种“有协议”的、更彻底地面向资源的服务方式。然而凡事都有两面离开了HTTP它又面临着几乎所有RPC框架所遇到的那个如何推广交互接口的问题。