rest 素材
内容提要
文章回顾了REST兴起前的Web开发：前端受同源策略限制，跨域需经后台代理访问SOAP服务，过程繁琐且依赖特定语言。作者认为SPA才是真正的前后端分离，早期因网站思维、性能不足及跨域规范缺失而不流行，后随缓存技术及Vue等框架兴起。REST本质是设计理念，强调资源、无状态、URL仅用名词、以HTTP动词实现增删改查、JSON返回、状态码、版本与Token。作者认为REST适合开放API，内部接口应灵活借鉴其优点。
延伸解读
从代理到直连：跨域限制如何塑造早期Web架构
文章指出，早期JavaScript受同源策略限制，无法直接访问SOAP服务，必须通过网站后台代理转发，且不同语言需生成各自的代理类，过程繁琐。这导致业务逻辑被绑定在网站后台，难以复用。作者由此反思后台的意义，提出将业务提取为独立服务、后台只负责静态资源的理想模式，这正是后来SPA的雏形。理解这一限制，有助于认识REST流行前Web接口设计的被动局面。
SPA迟来的原因：思维、性能与跨域规范
作者分析SPA早期不流行的三个原因：网站思维根深蒂固；频繁Ajax请求给服务器带来压力，而网页静态化技术已成熟；跨域访问缺乏标准规范。后来Memcache、Redis等缓存技术缓解了负载问题，加上Vue、AngularJS等框架支持，SPA才真正流行。这说明技术模式的普及往往依赖配套基础设施的成熟，而非单一理念的先进。
REST的实质：设计理念而非技术
文章强调REST不是技术，而是设计理念，核心是“服务即资源”。其特点包括：基于资源、无状态、URL只用名词、用HTTP动词表示增删改查、使用JSON、利用状态码、版本与Token。作者特别指出，网站中GET/POST的选择基于简单或复杂，而REST中GET对应查询、POST对应新增，意义完全不同。理解这一点是正确设计RESTful API的关键。
开放API与内部接口：REST的适用边界
作者根据经验总结：RESTful API适合开放API（如豆瓣、GitHub），因为开放方不知道客户端需要什么，返回完整资源模型更通用；但内部开发中，接口粒度和返回结果过于“粗”，客户端只需一个字段却收到十几个，不友好。因此内部接口应灵活借鉴REST优点，不必严格只写四个接口，但错误码、状态码等优秀特性必须保留。这提醒读者根据场景权衡，而非盲目套用。
Q&A
在REST流行之前，前端如何跨域访问SOAP服务？
前端JavaScript受同源策略限制，不能直接访问SOAP服务，需要先访问自己的网站后台，再由后台代理访问SOAP服务。而且不同语言的网站后台需要生成特定语言的代理类，过程繁琐且依赖语言。
为什么早期SPA（单页面应用）不流行？
早期SPA不流行的原因有三个：一是网站思维根深蒂固；二是性能考虑，频繁Ajax请求给服务器造成巨大压力，而网页静态化技术已成熟；三是前端跨域访问缺乏标准规范，各种跨域方法不好用。
RESTFul API的设计特点有哪些？
RESTFul API的设计特点包括：基于资源，一切数据和服务都是资源；无状态，每次调用独立；URL中只出现名词，不出现动词；URL语义清晰明确；使用HTTP的GET、POST、DELETE、PUT表示增删改查；使用JSON而非XML。
RESTFul API有哪些最佳实践原则？
最佳实践包括：使用HTTP动词表示增删改查（GET查询、POST新增、PUT更新、DELETE删除）；返回结果使用JSON；正确使用HTTP状态码（如200、201、401、403等）；错误时返回错误码；API必须有版本号（如v1）；使用Token令牌进行身份校验和权限分级；URL大小写不敏感，使用连字符-而非下划线_；提供漂亮的文档。
RESTFul API适合所有场景吗？内部开发好用吗？
RESTFul API并非所有场景都好用。对于开放API（如豆瓣、新浪微博、GitHub）非常合适，因为开放API不知道客户端需要什么，返回完整资源模型通用性强。但对于内部开发不好用，因为接口粒度和返回结果过于“粗”，通常返回完整数据模型，而内部需求明确，服务器不应简单甩资源实体给客户端。内部开发可以灵活借鉴REST优点，保留错误码、状态码等优秀特性，但不必严格只写增删改查四个接口。
REST中的GET/POST与普通网站中的GET/POST有何不同？
在普通网站中，GET和POST的选择基于简单用GET、复杂对象用POST；而在REST中，GET对应查询一个资源，POST对应新增一个资源，意义完全不同。理解这一点对设计RESTFul API非常重要。
