phpios接口技巧_PHP企业开拓高可用接口做事系统面向世界的接口参数设计

这便是我最早正式打仗接口做事系统开拓的机遇，并因此和接口系统结下了深厚的缘分。
毕业后步入职场，连续将自己的生嫩的开拓框架运用在实际商业项目开拓中并持续完善优化，一段韶光后，在框架稳定并趋于成熟时，我把它作为一个PHP开源框架正式发布上线，命名为：PhalApi，一个PHP轻量级开源接口框架。
它的slogan是：助你创造代价！

此开源框架又经由数年的发展，逐渐受到了广大开拓职员的认可，并分别运用在电商、医疗、旅游、游戏等行业，为更多的商业项目或非盈利项目而供应快速开拓的技能根本与办理方案。
在补充了相对完全的开拓文档外，与此同时我也编写了《初识PhalApi：探索接口做事开拓的技艺》电子书，揭橥在图灵社区。

在这一章，我们再一次连续探索接口做事系统。
可以说，这部分是《初识PhalApi：探索接口做事开拓的技艺》一书的简化版，再简化版，但提及的内容和关注点又会有所不同。
一方面，此章节更多关注的是如何站在业务角度开拓高可用的接口做事系统，无论是利用框架，还是不该用框架，都是可以遵照本章所先容的技艺进行设计和开拓。
另一方面，也是最主要的，本章会结合我多年的接口开拓履历，结合一线开拓的现状以及大型企业级系统开拓的约束，全面分享和讲解如何搭建一套更加完善的接口系统，使之能匹配繁芜领域需求发展的须要、知足苛刻的特质、并能与其他业务系统共振从而产生更大的凝聚力。

研发接口框架与开拓接口做事系统，有着奇妙的差异。
前者更关注的是如何直接帮助接口开拓职员更好的完成详细的项目开拓，为工程师供应友好的接口和设计，减少学习和入门的本钱，并间接尽可能能知足业务开拓的须要。
而后者，则重点聚拢于领域业务的开拓，面临的是业务逻辑处理与业务需求的快速迭代，同时兼顾客端调用、场景利用和系统之间的对接。

根据随着韶光推移而利用的通讯协议的不同，可以得到相应协议背后不同实现办法的接口系统。
较早期，采取的是SOAP（Simple Object Access Protocol）大略工具访问协议，并与XML可扩展标记措辞一起，用于构建Web Service。
我当时毕业论文设计采取的技能紧张也是Web Service，但当前在实际商业项目中利用较少，只有极少数部分海内企业或国外的技能公司才能连续沿用Web Service。
随后，行业内涌现了RPC（Remote Procedure Call）远程过程调用协议，对应的开拓类库有PHPRPC。
比较于Web Service，PHPRPC会更为轻量。

现在，大部分接口系统利用的是路人皆知的HTTP协议，和比XML格式更为简洁的JSON格式一起，组合成：HTTP+JSON+API。
这一实现办法，也是我从毕业后到现在，在从事职业开拓过程中，见到利用范围最广的实现办法，包括但不限于开源框架、个人项目、初创公司、中小型接口系统、大型企业级中间层接口。
因此，在本章的高可用接口做事系统中，我们也以此实现办法为主。

另一方面，如果基于接口系统的规范和设计理念进行分类，又可分为RESTful和微做事。
RESTful是一种软件架构设计风格，它的核心思想是：万物皆为资源，并制订了相应的规范，更多内容推举阅读《RESTful Web APIs》一书。
而微做事是由Martin Fowler大师近几年提出来的观点，并广为流传和被引用。
如果之前尚未打仗过微做事的同学，可以关注微做事的这几点主要特质：

微做事，可以说是当下接口系统混乱开拓的一剂良药，为我们开拓接口系统供应了很多启示性的帮助，以是我们这一章也因此微做事为根本的辅导思想，致力于为客户端供应高可用的接口做事。

前面我们按接口系统内部的实现技能或设计办法进行了技能分类，另一方面，也可以根据调用的客户端进行分类。
而这种分类的做法，能让我们更加侧重于业务端、客户真个利用场景和业务须要进行考虑和设计。
如果说，对付商家来说，“顾客便是上帝”，那么对付我们做事端开拓工程师来说，也应秉持“客户端便是上帝”的做事态度。
接口做事该当是做事于客户端，而不是限定客户端。
不能是“我们做事端有什么，你们客户端就用什么”，而是该当提倡“我们客户端须要什么，我们做事端就供应什么”。

为什么这么说，是由于接口系统开拓团队和客户端开拓团队是从属于不同的行政部门，在日常跨部门协作与沟通过程中，常常会发生优先级不一致或沟通不顺畅的情形，更糟糕的是有时会闹得两边的开拓团队都不愉快。
因此，作为做事端开拓同学，我们该当始终以友好的态度，做事于我们的客户端，只管即便供应客户须要的接口做事，不管内部实现有多困难。

言归正传，紧张的客户端为：浏览器（包括PC端和M端）、App移动运用、做事端系统。

如果客户端是浏览器，那么我们须要对接的是前端开拓工程师，他们紧张利用的编程措辞是Javascript，并且须要在兼顾PC版和M版的同时还要小心翼翼留神浏览器兼容性的问题。
或是出于前后端分离的考虑，又或许是传统异步加载的做法推动，我们须要为浏览器供应JSON格式的数据接口，以便浏览器客户端可以进行Ajax调用。
此时，基于客户真个特点，须要考虑是否存在跨域问题、是否须要支持JSONP并预防XSS攻击、是否须要全站切换HTTPS协议以及HTTP协议下兼容和过渡的考虑、是否适宜为接口结果采取CDN缓存及其应急刷新机制……更主要的一点是对付安全性的设计，一方面要防止恶意爬虫对主要商业数据的抓取，另一方面要对用户的敏感个人信息获取与操作时须要进行登录态的身份校验。

如果客户端是App移动运用，那么安全性会相对高一些。
由于可以在客户端和做事端之间进行署名校验，虽然也会有被逆向工程破解的可能，但比较于源代码的Javascript，利用Java开拓的安卓运用以及利用Object-C/Swift开拓的iOS运用，经由编译后的识别难度更大，破解更难。
与此同时，移动运用可以说更为灵巧，由于可以在很大程度上不受浏览器的约束和限定，例如App可通过WebKit等其他办法内嵌H5页面。
但对付移动运用，我认为最为值得关注的是不同版本的App运用与做事端接口之间的兼容性问题。
一定要服膺，在开拓App新版和升级接口系统的接口做事时，要考虑对旧App版本的兼容。
如有必要，还应供应不同编程措辞的SDK包，以便客户端快速开拓和接入。

末了，我们还有一个分外的客户端，它不是直接被终端用户利用的运用、页面或软件，而是同样运行在做事真个系统。
也便是说，此时的客户端，它本身也是做事端系统，很可能也是接口做事系统。
如果客户真个系统和做事真个接口系统都是同一公司内的系统，那么就须要考虑进行内网支配，乃至同机房支配，也便是我们常说的内网接口做事系统。
如果是供应给外部公司或者第三方系统接入利用的，则要考虑是否搭建一个接口开放平台。
例如国外的Facebook、Twitter、Amazon开放平台，又如海内的微信开放平台、支付宝开放平台、新浪微博开放平台等。
这时，要考虑接入掌握、权限掌握、配套的计费系统以及掌握台管理界面。

以上两种分类的办法，即按技能分类和按客户端分类，前者是帮助了我们梳理接口系统内部实现的要素和关键点，后者则是为我们搭建更加完善配套的接口做事生态系统而供应更多的思考。

这一节，紧张谈论的内容是接口的输入，包括接口参数校验、电子署名、身份验证、权限掌握等安全性的话题。
在这中间，我们还扩展延伸了配置优于实现这一思想的磋商。
接口的输入，是客户端与做事端之间的桥梁，也是两者之间的安检环节。
我们既要担保两端之间通讯的友好性，又要担保做事端不受造孽要求的攻击或侵害。

在我第一次正式演习的时候，就开始参与了接口系统的开拓事情，并且在那时正式打仗了接口参数这一观点。
当时我创造一个非常有趣的征象，那便是接口项目代码中，到处充斥着对接口参数验证、解析、处理、原始的重复代码。
而参与掩护这些代码的同事，不知道是没故意识到这些代码异味，还是未能察觉接口参数验证背后的共性，对此部分的实现既不做任何改进和优化，也不总结提炼。

然而，秉持着KISS原则和DRY原则，以及出于对接口参数验证这一眇小领域的兴趣，那时我就开始考试测验对这部分进行思考、剖析和设计。
我希望自己能合理、恰当地封装接口参数的全部操作，包括判断参数是否通报、默认值的设置 、类型的转换、数据合法性的检测，乃至包括接口参数的描述与文档的结合。
经由一段韶光的努力，对接口参数验证的封装已初见雏形，我将它运用在日常的项目开拓中，极大肃清了重复的代码，同时更优雅地完成了对接口参数的操作。

当然，我也希望自己对接口参数验证的提炼也能供应或开放给更多的技能开拓职员利用。
他们只要大略地写一行代码，乃至不须要编写代码而只需大略配置一下，就能实现他们期望的操作。
而在这背后，接口参数验证会自动，且略带智能地完成剩下的事情。
如果可以，我更希望这些可以成为一种规范，一种被广为接管的约定。

怀着这样的初心，从演习到毕业设计，从全职事情于各商业项目和系统的开拓到正式投身开源社区，最初的接口参数验证，经由不断演进，逐步完善，现在成为了PhalApi开源接口开拓框架中不可短缺的一部分。
在PhalApi中供应的参数规则，友好地供应了对接口参数规则的定义、配置和描述等。
通过对参数的规则配置，而不是对参数进行原始化的代码编写，明显提升了开拓的效率和质量，受了浩瀚开拓职员的喜好。
除此之外，这些参数规则，还可以用于自动天生接口在线文档，一举多得。
正由于如此，这些参数规则成为了PhalApi开源框架中规范和标准，乃至还有开拓同学将此模块抽离运用在其他的项目和框架中。

下面，我们通过一个大略的登录接口为例，粗略感性认识一下PhalApi框架的参数规则。
如果利用的是PhalApi 2.x 版本，在接口实现类中，可以利用以下配置示例对登录接口的账号和密码这两个参数进行掌握。

<?phpnamespace App\Api;use PhalApi\Api;class User extends Api { public function getRules() { return array( 'login' => array( 'username' => array('name' => 'username', 'require' => true, 'min' => 1, 'max' => 50, 'desc' => '用户名'), 'password' => array('name' => 'password', 'require' => true, 'min' => 6, 'max' => 20, 'desc' => '密码'), ), ); }}

这里，针对/?s=User.Login接口做事，配置了两个参数，一个是账号username，一个是密码password。
根据上面的配置，不难明得，账号和密码都是必传参数，并且账号的最小长度为1，最大长度为50；密码的长度则介于6和20之间。

class User extends Api { …… public function login() { $username = $this->username; // 账号参数 $password = $this->password; // 密码参数 // 更多其他操作…… }}

配置好参数规则后，对参数的获取就非常大略了。
由于，只须要利用类属性的办法，就能获取对应的参数。
正如上面看到的$this->username和$this->password，分别表示账号参数和密码参数。
这些类成员属性名称与参数规则中的数组下标值对应。

若客户端通报了合法的账号和密码，相应的参数会自动添补到类成员属性。
如果客户端什么参数也不供应，则接口做事会返回类似这样的缺点提示：

{ "ret": 400, "data": [ ], "msg": "客户端造孽要求：短缺必要参数username"}

除了参数的解析和验证外，通过参数规则，还可以指天命据来源，例如限定来自POST参数、GET参数或者COOKIE等。
如果现有的参数规则类型不能知足项目的开拓须要，还可以自行扩展添加所须要的参数类型。
与其他开源框架一样，PhalApi的参数规则也能支持回调函数的配置与调用。
概括起来，共有9种内置参数类型，分别是：

更酷的是，框架会自动根据配置的参数规则自动天生在线文档。
刚刚配置的账号和密码参数，对应自动天生的文档，局部截图类似如下：

图8-1 账号与密码参数

以上，都是参数规则的外在表现，但我更想和大家分享的是背后的实现、设计和思路。
可以说，整套参数规则体系的布局都是环绕着可重用性、易用性和友好性开展的。
从大到小，自顶而下，关键的环节扼要总结有：

首先，我们要在框架的核心实行过程的得当位置，添加对参数规则的入口调度。
这个机遇便是在接口类基类PhalApi\Api::createMemberValue()方法内，它要完成的任务是，根据配置的参数规则把客户端通报的参数转换成接口类的成员属性。

图8-2 PhalApi 2.x的核心时序图

打开PhalApi 2.x的源代码，可以看到这里的实现只是一个foreach循环，这是观点视角的高度抽象，在它背后则是规约视角和实现视角的细节。
先来看下入口源代码的写法：

<?phpnamespace PhalApi;class Api { / 按参数规则解析天生接口参数 根据配置的参数规则，解析过滤，并将接口参数存放于类成员变量 @uses Api::getApiRules() / protected function createMemberValue() { foreach ($this->getApiRules() as $key => $rule) { $this->$key = DI()->request->getByRule($rule); } }}

把稳到，这里面依赖了其余两处的实现，一个是多套参数规则的合并， 另一个是根据规则获取参数。
将多套参数规则的合并的实现放到接口类内是经由精心设计的。
由于参数规则的配置本身就直接来源于接口类的getRules()钩子方法，即来自接口实现子类本身，再进一步，这里的参数规则又可再细分为通用接口参数规则和指定接口参数规则。
其次，还有一个缘故原由是由于在接口类内处理配置文件./config/app.php中的apiCommonRules公共参数，也更为贴切。
末了，对付配置了白名单的接口做事，还可以在接口类这一层做临时的动态调度。
细细品来，这是一个奇妙的设计。

接下来，让我们把放大镜挪到PhalApi\Request::getByRule()，连续探索根据规则获取参数的奥妙。
此刻，会在要求类Request内完成参数获取的操作，为什么放到Request类也是有缘故原由的。
第一，要求类蕴含了各种来源的参数，例如：$_POST、$_GET、$_COOKIE、$_SERVER、$_REQUEST，可以直接从中提炼出须要的数据源；第二，如果短缺必要参数，则可以在这一环节直接抛出非常，给客户端相应的缺点提示；末了但不是最主要的，我们还可以对做事端配置的参数进行合法性的校验，以及完成对底层的调用。
下面源代码很好诠释了这三层意思。

<?phpnamespace PhalApi;class Request { / 根据规则获取参数 根据供应的参数规则，进行参数创建事情，并返回缺点信息 @param $rule array('name' => '', 'type' => '', 'defalt' => ...) 参数规则 @return mixed @throws BadRequestException @throws InternalServerErrorException / public function getByRule($rule) { $rs = NULL; if (!isset($rule['name'])) { throw new InternalServerErrorException(T('miss name for rule')); } // 获取接口参数级别的数据集 $data = !empty($rule['source']) && substr(php_sapi_name(), 0, 3) != 'cli' ? $this->getDataBySource($rule['source']) : $this->data; $rs = Parser::format($rule['name'], $rule, $data); if ($rs === NULL && (isset($rule['require']) && $rule['require'])) { throw new BadRequestException(T('{name} require, but miss', array('name' => $rule['name']))); } return $rs; }}

连续把镜头放大，拉近我们与第4个环节统一格式化操作的间隔。
考虑到在大部分情形下，字符串string是利用频率最次也是最为通用的类型，因此如果没有指定参数类型，默认类型便是字符串。
而对付没有指定参数默认值的话，则默认值为NULL。
完成这些必要的初始化和准备事情后，就到了表示PHP动态脚本措辞上风的地方了。
根据开拓职员配置的参数规则中的类型，可以组装成既定的格式化详细实现类名称，结合依赖注入，实现单例模式下对格式化类实例的资源管理，末了调用统一接口规约下的接口PhalApi\Request\Formatter::parse()。
出于对章节完全性的考虑，请许可我再贴下干系的源代码片段。

<?phpnamespace PhalApi\Request;/ Parser 变量格式化类 /class Parser / 统一格式化操作 / public static function format($varName, $rule, $params) { …… return static::formatAllType($type, $value, $rule); } / 统一分发处理 / protected static function formatAllType($type, $value, $rule) { $diKey = '_formatter' . ucfirst($type); $diDefautl = '\\PhalApi\\Request\\Formatter\\' . ucfirst($type) . 'Formatter'; $formatter = \PhalApi\DI()->get($diKey, $diDefautl); if (!($formatter instanceof Formatter)) { throw new InternalServerErrorException( \PhalApi\T('invalid type: {type} for rule: {name}', array('type' => $type, 'name' => $rule['name'])) ); } return $formatter->parse($value, $rule); }}

末了一步，我们终于迎来到了剧情的大结局。
前面有说到，PhalApi 2.x内置了9种参数类型，并且默认类型是字符串。
以是，以字符串的格式化实现类StringFormatter为例，举一反三，从而理解其余8种格式化实现类的思路和自定义扩展格式化类的开拓规范。

<?phpnamespace PhalApi\Request\Formatter;/ StringFormatter 格式化字符串 /class StringFormatter extends BaseFormatter implements Formatter { / 对字符串进行格式化 / public function parse($value, $rule) { $rs = strval($this->filterByStrLen(strval($value), $rule)); $this->filterByRegex($rs, $rule); return $rs; }}

这一层是属于实现视角，更多是实现细节，包括但不限于对参数进行类型转换，范围检测和反序列化解析。

整套设计终极映射到代码模型，涉及到的类、依赖关系和包嵌套层级，可以参考利用PHPDoc天生的图形。

图8-3 参数规则格式化类图

至此，我们就已经快速领略了PhalApi 2.x中参数规则的实现思路和微架构设计。
在《初识PhalApi》一书中，我更多先容的是如何利用参数规则，在这里，我重点分享的是如何站在框架的角度为技能开拓职员设计一套友好、易用的参数规则。
如果你也打算这么做，可以轻微参考一下这里的做法。

当然，除了重复造轮子，更推举的做法是直策应用开源框架供应的验证器。
例如Yii的声明验证规则，包括CFormModel表单验证和和CActiveRecord模型验证；其余又如Symfony的Validation验证。
从某种程度上说，验证这块是个非常值得深入研究的细分领域，也已经不少精良的资料对此进行先容和总结。

下面，我们再来大略回顾或理解下Yii和Symfony对参数验证的利用办法。

摘自Yii 1.1 威信指南，有以下示例：

class LoginForm extends CFormModel{ public $username; public $password; public function rules() { return array( array('username, password', 'required'), array('password', 'authenticate'), ); } public function authenticate($attribute,$params) { …… }}

在登录表单中，为账号和密码配置了相应的规则，个中账号和密码都是必须的，并且密码还会通过LoginForm::authenticate()再做进一步的验证。

PhalApi的参数规则，很大的灵感来自Yii。
由于Yii中有很多可以通过配置就能实现的功能，除了表单验证外，还有模型、视图组件等。
这些配置都很强大，但强大到有点繁芜，乃至难以影象和利用。
每次我在利用Yii开拓时，都要到官网搜索一遍，找到类似的示例代码或者查看类手册才能知道该详细如何配置。
以是，在设计PhalApi参数规则时，我在基于Yii的灵感上做了一些创新，只管即便做到易用和大略。
顺便分享一下，很多出名的画家，都是从临摹他人的作品开始的，只有在交融贯通后，再加入自己的思想，方能设计出更加博识的艺术品。
同样的道理，在设计框架时，也该当这样，集百家之精华于一身，博取众长，方能研发出更为知心动人的项目。

另一方面，摘自Symfony官方文档，我们也可以看到表单验证的干系配置。

public function buildForm(FormBuilderInterface $builder, array $options){ $builder ->add('myField', TextType::class, array( 'required' => true, 'constraints' => array(new Length(array('min' => 3))) )) ;}

纵使未曾利用过Symfony框架，也不难明得上面配置的意思：对付字段myField，指定了文本类型，并且是必须字段，最短长度是3。
多么普通易懂啊。
逆向还原随意马虎，同样正向利用也民平易近。

配置的魅力如此之大，以至于我不得不单独用一节的篇幅再对其进行总结和分享。
简而言之，本节基于我们都认可这样的代价不雅观为条件，即致力于编写人随意马虎理解的代码。
而配置则是通过此代价不雅观的绿色通道。

首先，老例优于配置。

Ruby是一门精良的编程措辞，而且也处处表示了老例优于配置的理念。
通过大略的代码示例，可以体会这一约定。
如普通的操作：

def say_hello(name) # 先打声呼唤 puts "hello #{name}"end

对付返回布尔类型的操作，则在方法名后面添加一个问号。

def more_money?() # 假设有点钱 return trueend

对付一些危险的、可能会抛出非常的操作，则会在方法名后面追加一个叹号。

def borrow_me!(money) # 假设钱不足 raise "Not enough momey!"end

为了串联进来，假设有这么一个用户故事：你好某某人，有钱吗？借一点给我吧！
则对应的代码片段可以表达成：

say_hello '某某人'borrow_me! 100 if more_money?

对应运行的效果类似如下：

hello 某某人./test.rb:13:in `borrow_me!': Not enough momey! (RuntimeError)

就这么一个大略的案例，可以体会到Ruby元编程措辞下约定成俗的做法，而这些大大小小的约定，不仅没有增加开拓职员的认知包袱，反而构成了Ruby开拓职员的共同开拓措辞。
无需过多的阐明，Ruby程序员都有快速解读这些符号和约定背后的含义。

其次，配置优于实现。

可以说，拥有老例的开拓团队，会有更高效的互助以及更为畅快的沟通。
由于大家都能快速明白简明代码所表示的意图和目的，不存在稠浊和错乱。
如果短缺开拓措辞的特性支持，或者所在的开拓团队短缺约定编程的氛围，可以退而求其次，采取配置优于实现的做法。

关于配置的做法，在以利用表明的JAVA为例，可以看到其身影，如须要运行一组单元测试，可以这样：

@RunWith(Suite.class) @Suite.SuiteClasses({ Test1.class, Test2.class, Test3.class, TestSuite2.class }) public class TestSuite1 { }

相称于以下JUnit 3中的实当代码：

public class TestSuite1 { public static Test suite() { TestSuite suite = new TestSuite("Test for package1"); suite.addTest(new JUnit4TestAdapter(Test1.class)); suite.addTest(new JUnit4TestAdapter(Test2.class)); suite.addTest(new JUnit4TestAdapter(Test3.class)); suite.addTest(new JUnit4TestAdapter(TestSuite2.class)); return suite; } }

注：以上代码摘自 https://blog.csdn.net/ccjjyy/article/details/6182109

通过配置，而是不编码实现，可以更随意马虎传达所须要做的事情，而且配置的背后则是更为规范同等的约定，以及更为严格的检测，从而减少人为的失落误的机会。
末了，不仅是效率的回报，还是高质量上的获益。

而这一点，和我们在PhalApi、Yii、Symfony中利用配置所达到的效果是类似的。
以PhalApi的参数规则为例，除了可以用规则配置取代重复实现的代码外，开拓职员还可以利用参数规则库来掩护全体项目的规则，乃至还可以将这些配置进行序列化存储，再通过可视化的管理后台进行在线掩护和管理。
这都得益于配置的运用。

在过往的开拓中，我也曾碰着类似的场景，在开拓活动系统的功能时，我创造可以把类似常用的活动功能开拓抽离成可配置的形式，末了也印证了采取配置而不是实现编程，可取得效率上的提升以及高质量的回报。
在曾经关于设计模式的分享里，我把这一模式总结为：开拓-配置-利用模式 (DEVELOP-CONFIG-USE PATTERN)。
它概括起来是：

在配置的根本上，我们可再向前一步，向声明式编程靠拢。
配置式编程固然是好，但视不同的高下文而定，有时还可以再进一步，进入到声明式编程的范畴。

考虑以下表单，

图8-4 登录表单

对登录表单数据进行验证的JavaScript代码片段如下：

validator.init([{ dom: iptMobileDom, rules: [{ strategy: 'isNotEmpty', errorMsg: '手机号码不能为空' }, { strategy: 'isMobile', errorMsg: '手机号码格式缺点' }] }, { dom: iptAuthcodeDom, rules: [{ strategy: 'isNotEmpty', errorMsg: '验证码不能为空' }] }]);

上面的代码不难明得，浸染是对手机号和验证码进行验证，并且通过配置规则可以快速实现对表单的验证。
但这样依然有两个缺陷：一是详细的规则不能直不雅观解释须要验证的内容，二是当其他场景须要进行类似验证时须要重复编写相同的规则。
也便是说，虽然我们有了规则配置，但还是嫌它过于繁琐，那有没有更“

答案是：有的！
我们可以采取声明式编程，即：我们该当见告代码（同时传达给我们的差错），我们须要验证什么，而不是着重于详细要怎么验证。
听起来，便是第四代编程措辞。

首先，可以定义一个规则凑集常量：

const rules = { mobile : { isNotEmpty : { strategy : 'isNotEmpty', errorMsg : '手机号码不能为空' }, format : { strategy : 'isMobile', errorMsg : '手机号码格式缺点' } }, authcode : { isNotEmpty : { strategy : 'isNotEmpty', errorMsg : '验证码不能为空' } } };

接着，利用上面元规则进行自由地组合利用，声明须要验证的内容。
调度后的代码为：

validator.init([ { dom : iptMobileDom, rules : [rules.mobile.isNotEmpty, rules.mobile.format] }, { dom : iptAuthcodeDom, rules : [rules.authcode.isNotEmpty] } ]);

这样之后，再来看下其他类似的场景，我们纵然不细看扩展丰富后的规则，也可以很随意马虎理解明白下面代码的意图。

validator.init([ { dom : iptPasswordDom, rules : [rules.password.isNotEmpty, rules.password.format] }, { dom : iptMobileDom, rules : [rules.mobile.isNotEmpty, rules.mobile.format] }, { dom : iptAuthcodeDom, rules : [rules.authcode.isNotEmpty] } ]);

在上面常见的表单验证的场景中，可以创造个中一些奇妙的关系。
须要待验证的DOM节点是可变的，由于不同的场景界面会有不同的class，同时须要进行验证的条件也是可变的，即会存在组合的情形。
但是各个规则条件又是可以共用的，末了每一条规则条件都是可重用的一条元规则。
故此，把不变的元规则抽取成规则凑集，既方便重用，又能匆匆进开拓职员之间跨时空的理解。

轻微提炼一下，便可得到以下的设计模型：

图8-5 表单规则的设计模型

为什么说老例优于配置，配置优于实现呢？由于对付要做一件事宜，老例可以说是不用写任何代码就能轻松实现的；配置是须要大略地写一些任何措辞都能识别的普通字符就可以了；而实现则是须要根据不同的编程措辞而进行详细的开拓。

再次回顾观点视角、规约视角和实现视角这三种面向工具的视角，详细的实当代码则是对应了实现视角，再说得普通一点（但不一定是对的），老例为上策，配置为中策，实现为下策。

如果说客户端供应的参数是不可信赖的话，那么对付客户真个身份和来源则更要谨慎判别，最大限度全面提升接口做事系统的防护能力和安全性。
至少有以下这几个方面，我以为是有必要负责考虑的。

下面分别大略说之。

不同于网站，不同于直接面向终端用户的系统，接口做事系统的直接客户实际上是手机设备、第三方系统、嵌入式硬件等，而不是活生生的人群。
因此，首先我们要方案好等接入的渠道接入方，以便管控各个渠道的访问、版本掌握等。
如果开拓的接口紧张为移动设备的运用供应做事，那么我们就要区分好是iOS还是Android，是App 1.0 还是App 2.0，是内测版还是公测版。
如果客户端紧张是公司内部业务系统，就要区分好是哪个业务系统，为不同的接入渠道分配单独的凭据，方便在涌现问题或者流量非常时快速定位业务干系方。
如果我们搭建的是一个开放式的接口平台，那么渠道接入方的管理就更不可少了。
这些管理包括渠道的有效日期、各自的密钥、主体信息、要求统计，乃至还包括计费系统。

HTTP可以说是一个公开透明的通讯协议，每次要求所通报的参数都是一览无遗，就像一个光秃秃的小屁孩，走在大街上，毫无隐私可言。
如果不采纳任何保护方法，我们的接口做事就会很随意马虎受到假造的要求。
因此，我们引入了电子署名这一观点。
署名是指客户端根据接口做事系统分配的唯一凭据和密钥，根据约定的署名算法进行身份验证。
只有当署名核对精确后，才认为是合法的要求。
署名验证的算法设计很大略，在PHP在利用ksort、http_build_query、md5等函数就能快速设计一个大略可靠的方案了。

HTTP协议除了是公开透明外，还是一个无状态的要求，不带影象功能。
虽然也可以通过COOKIE或SESSION来增强会话的能力，但常日不建议在接口做事系统中利用这一方案，这也是为什么PhalApi开源框架一贯都没有供应对SESSION的封装和接口。
更好的做法是，在用户成功登录后，为用户当前会话分配一个TOKEN登录凭据，然后后续客户端在要求接口做事时带上此TOKEN参数。
就可以在确保是合法的客户端要求的同时，确保是真实的用户本人。

话说回来，一个光秃秃的小屁孩穿梭在人群中，难免不雅观观，因此我们可以帮他穿上衣服，或者在别人看到这个短视频前打上马赛克。
同样在接口利用HTTP通讯的过程中，我们也可以对客户真个要求以及做事端返回的结果进行加密通讯。
例如利用RSA加密算法，这一做法在银行供应的接口做事系统中运用得较为广泛。
但在一样平常的普通商业项目中，过重的加密通讯反而会影响客户真个易用性，这一点须要权衡。

末了，是接口做事系统的权限掌握。
权限掌握在系统层面是针对渠道接入方的权限掌握，可以指定特定渠道接入方可以利用哪一类或哪部分接口做事。
在业务层面，还可以细分掌握当前已登录的用户具备哪些操作的能力或权限，例如分为游客、普通会员、高等会员等。
在设计时，可以参考基于角色权限掌握的RBAC，或访问权限掌握的ACL。

综合渠道接入方的区分、署名校验、登录态检测、加密通讯、权限掌握，都是从不同的侧面增强接口做事系统的安全性。
但要把稳的是，没有绝对的安全，只有相对的安全。
纵使全部这些都做到了，对付客户真个重复要求、爬虫的抓取，还是有所欠缺的。
在开拓接口系统过程中，要综合考虑，做出得当的设计。