在我用这个建站工具之前，我用 java ssm 框架写了个半成品博客的项目，包括前后台 (因为服务器成本高，暂时搁置)。在选择 typecho 之前呢？我又用过 N 多个 blog，你听过，你没听过我几乎都用了。决定这个是因为用着顺手

大家都写过不少程序，比如写个 hello world 服务类，然后本地调用下，如下所示。这些程序的特点是服务消费方和服务提供方是本地调用关系。 而一旦踏入公司尤其是大型互联网公司就会发现，公司的系统都由成千上万大大小小的服务组成，各服务部署在不同的机器上，由不同的团队负责。这时就会遇到两个问题： 1）要搭建一个新服务，免不了需要依赖他人的服务，而现在他人的服务都在远端，怎么调用？ 2）其它团队要使用我们的服务，我们的服务该怎么发布以便他人调用？下面将对这两个问题展开探讨。

近些年，互联网基础设备和技术迅猛发展，互联网玩法日新月异，稍不留神就 Out。整体网民的素质也在不断提升的同时，对互联网的体验也提出了新的高度和要求，众所周知智能背后意味着复杂，体验好背后也意味着互联网的架构越复杂。利益当先的前提下，最好的优化就是缓存，缓存在整个互联网的发展过程中作用可想而知。尤其在中国如此蹩脚的网络下，南电信北联通，中间坑的都是付费的用户和企业。越来越多的证明表明，网站访问速度越慢，用户流失的越快，要想加快网站访问速度，基于此背景条件下，缓存和反向代理更显的尤为重要。

此为前端开发团队遵循和约定的代码书写规范，意在提高代码的规范性和可维护性。 此规范为参考规范，不全是硬性要求，部分硬性约定见下一条书写规范，统一团队编码规范和风格。让所有代码都是有规可循的，并且能够得到沉淀，减少重复劳动。

看过太多 tcp 相关文章，但是看完总是不过瘾，似懂非懂，反复考虑过后，我觉得是那些文章太过理论，看起来没有体感，所以吸收不了。 希望这篇文章能做到言简意赅，帮助大家透过案例来理解原理。

反向代理（Reverse Proxy）方式是指以代理服务器来接受 Internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

现在看来，REST 在 2000 年那个时代确实是超前于时代的。但是 Web 开发者社区对于 HTTP 的设计意图存在着大量的误解，由此导致了对于 HTTP 的大量低效率的误用。 需要注意的是，REST 是一种设计风格而不是标准，如果一个架构符合 REST 原则，我们就称它为 RESTful 架构。

移动互联网时代，RESTful API 成为越来越重要的移动端和服务器端交互的形式。尤其是在很多互联网公司或者传统行业拥抱移动互联网的时候，一套设计良好的 Restful API 能够帮助互联网产品支持单服务端＋多客户端的场景。RESTful 架构本身是一个风格而不是一个标准，这也就意味着在具体设计时会有不同的实现。那么什么是好的 RESTful API 呢？笔者认为适合的是最好的，能够根据本身产品的业务场景和阶段设计出结构清晰，易于理解，扩展方便的 Restful API 就是最好的。本文将围绕笔者对 Restful 架构的理解展开讨论，欢迎大家拍砖。

涉及到了：元字符、字符转义、重复、字符类、分枝条件、反义、分组、后向引用、零宽断言、负向零宽断言、注释、贪婪与懒惰、处理选项、平衡组/递归匹配