接口总结

lsekfe · 发表于 2016-8-8 14:33:12

1,什么是接口 (interface) ?

接口泛指实体把自己提供给外界的一种抽象化物（可以为另一实体），用以由内部操作分离出外部沟通方法，使其能被修改内部而不影响外界其他实体与其交互的方式。

相比难懂的定义，我们可以用一个简单的示例进行了解：

Android、ios因为不能对数据库进行直接的操作，但由于业务的需求需要对数据执行操作，因此不管是用php、Java还是c+等语言开发，在这时都需要为其对接相应的数据。这时Android、ios只需要直接调用不同的开发语言为其提供的数据，就能达到操作数据的目的。这个数据获取的过程就是接口的使用过程。

接口是方法的抽象，如果不同的类有同样的方法，那么就应该考虑使用接口。
（1）接口是一个行为的规范、协议。其实就是类和类之间的一种协定,一种约束
（2）C#不支持多继承，但是他把这个功能交给接口来实现。
（3）类与类之间的系统资源调用方式不一样，导致他们之间的通信很困难，而接口可以屏蔽掉它们之间的差异，能使他们顺利通信。

2, 接口的安全性：

时间的有效性。因为token是由时间戳和特殊字符串md5而成，那么每次调用接口的时候，我可以把当前调用的时间戳记录下来(比如保存在一个数组中，以文件的形式存放)，然后在下次调用时判断请求的url中的时间戳在数组中是否存在，若存在则为恶意调用(因为若为正常调用，每次请求的url中的时间戳都是不一样的)。如此，便可防止接口被恶意调用。另外，随着调用次数的增加，存放时间戳的文件会越来越大，针对这个问题，可以不定期删除，即使有人*的保存一个url很长时间，然后某一天心血来潮，再来一次调用，接口也只会被恶意调用一次，不会产生影响。

制定一个token生成规则，按某些服务器端和客户端都拥有的共同属性生成一个随机串，客户端生成这个串，服务器收到请求也校验这个串。

缺点：随机串生成规则要保密。

服务器端接到请求用同样方法计算token，

1.传输过程中的安全问题
为了防止在不安全的网络环境下传输的数据被截获和篡改，api 接口必须使用 https 协议。

2.客户端的安全问题
在客户端对数据进行对称加密再提交的意义是非常有限的，因为key被暴露在客户端代码中。如果一定要加密，可以使用非对称加密算法。客户端加密的主要目的是避免关键数据以明文存储于内存甚至磁盘中，防止这些数据被用户篡改。

3.服务端的安全问题
这个问题关键就是不信任任何从客户端提交上来的数据（无论客户端设计得多么天衣无缝），每一个参数都要做检验。

了解更多的加密：http://developer.51cto.com/art/201511/495814.htm

接口问题

php调用接口最主要的就是使用curl抓取信息

接口是为了解决什么问题

是php是单继承，一个类只能有一个父类，为了解决这个问题就出现了接口，一个类可以实现多个接口

3, 接口测试主要考虑的问题:

1 各个模块连接集成起来的时候,穿越模块接口的数据会不会丢失;  -----确定数据完整

2 各个子功能组合起来,能否达到预期要求的父功能; ------集合后，达到需求目标

3.一个模块的功能是否对另一个模块的功能产生不利影响; -----集成后，不影响相关模块功能

   4.全局数据结构是否有问题;                   ------集成后，保证系统数据的正确性

   5.单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。 -------集成后，确保误差不影响系统功能及性能

Service层接口测试，大致有三种测试类型：接口逻辑测试、出错测试、路径测试
接口逻辑测试，对开发人员输写的JavaDoc进行测试，后根据JavaDoc来编写测试用例，（一般情况下JavaDoc需要包含前提条件，业务逻辑，输入参数，输出值的描述），在接口逻辑测试中主要是根据所描述的业务逻辑，进行用例的设计，主要目标是测试在正常输入的情况下能得出正确的结果，测试用例的设计方法跟黑盒测试差不多，主要运用等价类，边界值两种方法。
出错测试，做了接口逻辑测试后，可以正常使用了。为了保证数据的安全，及程序在异常情况的逻辑正确性，因此需要测试出错测试。出错测试主要考虑：空值输入（如当传入一个对象参数时，需进行NULL值的参数）、参数属性的测试（如输入一个未赋值参数）、异常的测试（制造一些异常的测试场景，测试的异常描述是否清晰）
路径测试，经过了上述处理后，单个的接口服务已经得到了保证，但是在业务流中是否满足了业务需求其实还是没有得到保证，路径测试的目的就是设计尽可能少的用例，来保证各种业务场景下数据是安全可操作的。

   6 接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中
6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡，可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到
6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。

接口注意事项
1  接口文档,必须遵守接口文档的要求
2  输出数据最好使用json,因为json有很好的跨平台性,目前主流的编程语言都支持json解析
3 线上的 API 必须保证所有接口正常且关闭所有的错误信息 => error_reporting(0)，在输出JSON 时，不能有任何其它输出，否则，客户端将解析数据失败，直接崩溃

1.要写接口文档

一定要写好接口文档，并按照模块写，而且还要书写规范，最好的格式是：
接口请求地址；请求参数（包括参数名、类型、是否必填）；测试参数举例；返回参数（参数名，并注明每个参数的含义、为了双方对接数据是否正确；以及多种情况的判断，需要有接口状态参数）。
这样哪怕以后项目很大，以不会照成维护困难的问题。

2.制定规范

开发前一定要定好一个规范，比如要定好数据返回的通用参数和格式、数据的编码。关于数据格式，用的比较多的有xml和json，我建议用json，因为json比xml的好处更多。

3.精简的返回数据

接口数据因符合需要什么返回什么的原则，比如要查询某个用户的余额和注册时间，网页里面的做法可能是select * from user where uid=1，但是接口一定要select balance,regtime from user where uid=1。因为接口返回数据是要有开销的，要流量的，能少返回数据就尽量少返回，这样可以大大的提高性能。

4.数据类型要严格

要注意数据的类型，整数类型的数据一定要转为int，因为app客户端开发的java、object-c语言对数据类型比较严格，类型不对会照成app闪退。

5.保证代码正确性

要验证保证代码正确无误，而且生成环境中要屏蔽掉错误，避免头部有额外的输出，照成返回的json等数据解析失败而导致app闪退等。

6.要优化代码的性能

app要求响应迅速，这样才能给用户比较好的体验感。所以移动接口端在处理业务逻辑的时候，要避免不要执行太复杂的sql语句，或者含有大量的循环，能做成缓存的尽量做缓存，比如将首页的热点模块信息可以存到redis缓存中。在不考虑网速的情况下，比较理想的接口响应时间应该是200毫秒以内。

7.不要随意更改旧接口

app不像网页，app一旦发布，有人使用之后，接口就不要乱修改了。以后升级也是，修改要在保证接口原有结构之上进行额外的扩展，否则会导致调用旧版接口的app出现bug。

8. 注意接口的安全

安全高于一切，必须要保证接口的安全。电话号码等敏感信息在传输的过程中一定要加密，否则可能会被别人抓包到。拿取用户信息的接口一定要验证权限，以防止接口被恶意调用，泄密用户信息，甚至篡改信息。

token设置：将请求参数去空后排序，并将数据用&符号连接成key=value&key=value的字符串，最后加上一个key（一般是用户注册后获得的Appsecret），最后将得到的字符串加密

加密方式分为两种，一种为非可逆加密比如md5,crypt,sha1，另一种为可逆加密，有分为两种，对称加密urlencode/urldecode 和 base64_encode/base64_decode，非对称加密一般要开启openssl扩展，使用公钥和私钥。公钥加密，私钥解密或者私钥加密，公钥解密等

数据格式的了解：

数据交换格式比较之关于数据格式编码及解析的难度：

　　在编码上，虽然XML和JSON都有各自的编码工具，但是JSON的编码要比XML简单，即使不借助工具，也可以写出JSON代码，但要写出好的XML代码就有点困难;与XML一样，JSON也是基于文本的，且它们都使用Unicode编码，且其与数据交换格式XML一样具有可读性。

　　主观上来看，JSON更为清晰且冗余更少些。JSON网站提供了对JSON语法的严格描述，只是描述较简短。从总体来看，XML比较适合于标记文档，而JSON却更适于进行数据交换处理。

在解析上，在普通的web应用领域，开发者经常为XML的解析伤脑筋，无论是服务器端生成或处理XML，还是客户端用 JavaScript 解析XML，都常常导致复杂的代码，极低的开发效率。

接口文档

接口信息

接口调用方式，是post方式还是get方式，接口的请求地址。

功能描述

一定要清晰的描述接口功能。

接口参数说明

说明参数值是需要哪个公司提供，并详细说明参数怎么生成的，例如时间戳，是哪个时间段的；参数是否必填，一些参数是必须要有的，有些是可选参数，一定要注意写清晰。