共计 3224 个字符，预计需要花费 9 分钟才能阅读完成。
古代网站越来越多的应用前后端拆散架构，先用前端 MVC 框架疾速堆砌出 SPA，再用 API 获取动态数据也曾经成为日常的开发内容；而用来连贯前后端的 API，其重要性也天然言而喻。做为一个前端码农，意识后端的 API 设计形式也是很重要的，明天让咱们针对 API 设计来一探到底。
HTTP 办法
毕竟是网站的前后端，其中间的通信究竟还是要依赖 HTTP 这个无状态的协定；在 HTTP 标准中定义了一系列的申请办法，其中较罕用的如下：
- GET：获取资源
- HEAD：与
GET同为获取资源，但只取回 Header - POST：提交资源
- PUT：替换指定的资源
- PATCH：批改指定的资源
- DELETE：删除指定的资源
- OPTION：询问与指定资源的沟通办法
在标准中也提到，不同的办法指的是对同一件事做不同的操作，并通过语意化的办法，让不同的操作失去预期的后果。
大家对 GET、POST 都不生疏，这是 HTML 的 <form action="..."> 所反对的两个办法；GET 是应用最频繁的，无论是获取得页面还是数据，个别都会用 GET，而 POST 则罕用在新增资源上，但因为 HTML <form action="..."> 不反对其余办法，在传统网站中可能会用 POST 处里除了获取数据之外的所有事件。
PUT 和 PATCH 通常都用在更新资源上，两者的差别是 PUT 的行为是取代整个资源，而 PATCH 则是更新局部资源；把两者对应到日常生活中的话，就好比在餐厅吃饭，整桌菜从新点是 PUT，另外加菜是 PATCH。
DELETE 通常用在删除资源；HEAD 与 GET 相似，但只取回 Header，通常用在测试资源是否存在上；OPTION 是询问这个资源应该要怎么获取，通常用在发送 CORS 的预检（preflight）申请。
目前讲的都是在标准中提到且倡议的个别用法，理论服务器的 API 怎么开发仍然是看实现的人；但通过语意化的办法去设计 API，相对能够让 API 对开发者更加敌对。
RESTFul API
后面所说只是标准，而且只波及到了 HTTP 办法；有没有更残缺的实现办法呢？
当然有，这就是大家耳熟能详的 RESTFul API；它由 Roy Fieldin 在 IEFT 开发 HTTP 规范的六年间继续钻研、验证的，并在 2000 年在他的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中所提出，是一种网络程序的设计格调；所谓的 REST 是 体现层状态转换（Resource Representational State Transfer）的缩写，简略说就是通过动词（HTTP 办法）、名词（URI/URL，代表指标资源）、内容型态（响应的内容，如 HTML、XML、JSON 等），让无状态的网络通信能通过 REST 的语意化设计，携带所有的状态进行通信，升高对网络的反复申请而造成的资源耗费。
例如假如有一个视频网站：myku.com，它的的 API 有可能就会是这样：
[GET] http://myku.com/v1/videos/ -> 获取 video 列表
[POST] http://myku.com/v1/videos/-> 新增 video
[GET] http://myku.com/v1/videos/MgphHyGgeQU -> 获取指定 ID 的 video
[PUT] http://myku.com/v1/videos/MgphHyGgeQU -> 批改指定 ID 的 video
[DELETE] http://myku.com/v1/videos/MgphHyGgeQU -> 刪除指定 ID 的 video除了所应用的办法之外，也要留神代表资源的 URL 的编写形式，不是 HTTP 办法与理论动作相符合就算是 RESTful API！
同样的，RESTFul API 只是设计格调而不是 HTTP 的标准，很有可能在设计时基于 RESTful 的精力，但理论开发的后果却齐全不是 RESTful 的格调；但不可否认的是通过 RESTful API 的设计格调，每个资源都会失去一个到对应的地位（URL），并能通过 HTTP 语意化的办法，对指定的资源做绝对应的互动，整体资源管理会变得十分有语意化并且清晰，这的确是一个优良的 API 设计形式。
标准与实现
在 HTTP 标准中提到要如何正确应用办法，如果咱们没有依照标准实现，会造成肯定的影响。
缓存
浏览器默认会对 GET、HEAD 这两个办法做缓存，如果通过 POST 而不是 GET 获取资源的话，浏览器及两头的代理服务器个别都不会实现缓存机制，这时就必须由前后端开发自行通过其余形式设置缓存。
在标准中尽管也提到了
POST在 Header 适合的状况下也能够缓存，但因为实际上通常把POST用在新增操作上，做缓存的话反而会造成不可预期的结果，大部分浏览器也都没有实现针对POST的缓存机制。
SEO
当搜索引擎的爬虫在扫网站时，如果发现须要通过 POST 获取的资源，为了防止造成意外的行为或副作用，通常不会尝试爬取 POST 响应的后果。
GraphQL
尽管 RESTful API 的设计格调长处很多，但也有一些难以避免的毛病。
例如在查找存在依赖关系的嵌套数据时，很有可能必须要通过屡次申请想要能力找到想要的后果；而随着我的项目架构逐步扩张，同一页面的材料也会越来越简单，可能须要多个起源的材料能力堆砌出页面，这时候 RESTful API 须要阐明每个资源地位的个性，就会使 RESTful API 显得不太好用；也因为当初挪动设施十分遍及，一个后端服务器可能须要服务于 PC 版网页、手机 APP 等多设施的需要，须要的数据可能不一样，RESTful API 也就必须要实现出多个性能相似的接口，API 会逐步变得宏大而且庞杂，绝对难以治理。
有需要就会有解决的办法。这时 GraphQL 就应运而生了，这是由 Facebook 提出的开源语言规范，通过 Schema 定义材料，再依附与 JSON 格局高度相似的查问语句获得查问的后果，它的次要特点是：
- 強类型
- 查问语句即文件
- 查问语句即响应的数据结构，不会有冗余的内容
- 对立的对外入口
- 能够多查问合并，一起返回
这些个性无效的解决了 RESTful API 在简单架构下的问题，使 GraphQL 充斥弹性、十分好用，社区也曾经有了宏大的的生态系统反对，例如 Apollo GraphQL 能够与三大框架深度整合，再加上多查问合并的个性，让 GraphQL 与古代框架中组件的概念完满符合。
毛病大略就是必须要把所有简单的数据拼接逻辑都实现在后端，对于习惯于 RESTful API 的开发者来说，须要付出不少学习老本。
值得注意的是 GraphQL 收回的全部都是 POST 申请，缓存机制必须仰赖开发者或是框架实现；例如在 Apollo Client 中，开发者必须依照利用场景，调整 fetchPolicy 的设置，防止快取造成的意外后果。
后记
本文的题目是我一位敌人去面试某大厂后端时的一道面试题，由这个题目引申出 HTTP 办法及支流的 RESTful API 设计格调，并对 GraphQL 做了简短的介绍，心愿以上内容可能帮到你。
本文首发微信公众号：前端先锋
欢送扫描二维码关注公众号，每天都给你推送陈腐的前端技术文章
欢送持续浏览本专栏其它高赞文章：
- 深刻了解 Shadow DOM v1
- 一步步教你用 WebVR 实现虚拟现实游戏
- 13 个帮你进步开发效率的古代 CSS 框架
- 疾速上手 BootstrapVue
- JavaScript 引擎是如何工作的？从调用栈到 Promise 你须要晓得的所有
- WebSocket 实战：在 Node 和 React 之间进行实时通信
- 对于 Git 的 20 个面试题
- 深刻解析 Node.js 的 console.log
- Node.js 到底是什么？
- 30 分钟用 Node.js 构建一个 API 服务器
- Javascript 的对象拷贝
- 程序员 30 岁前月薪达不到 30K，该何去何从
- 14 个最好的 JavaScript 数据可视化库
- 8 个给前端的顶级 VS Code 扩大插件
- Node.js 多线程齐全指南
- 把 HTML 转成 PDF 的 4 个计划及实现
- 更多文章 …