API-restful规范

概述：接口restful只是一个建议的规范，不一定都需要强制要求。实际开发中，只会在优先符合业务流程的情况下尽量去遵守，所以也可以不遵守，例如登录。早期开发的时候add order，delete order，update order，get order，随着业务增加，接口会越来越多。为了规范化接口开发，渐渐的引用不同的请求方式进行不同的业务接口处理。order订单，get,post,delete,put,patch就可以完成5种接口处理。根据不同的method不同做不同的操作。业务逻辑不变，编写格式变了而已。

总结起来有10个规范。

1、协议：API与用户的通信协议，使用HTTPS协议。（更安全，涉及了加密算法）

2、域名：采取以下域名标识的方法：api.baidu.com / www.baidu.com/api ，推荐后者，方便解决前者跨域问题。

3、版本：接口地址前缀添加版本。www.baidu.com/api/v1/ 或者放在请求头也可以。

4、路径：面向资源编程，视网络资源均可增删改查。推荐使用名词。URL：www.baidu.com/api/v1/ 名词

5、method：get，post，put，patch，delete：增删改查，局部更新。

6、过滤：通过在URL上传参的形式传递搜索条件。www.baidu.com/v1/user?stauts=1&page=1

7、状态码：单纯的状态码不够包含足够多的错误。建议：状态码+code的形式。

8、错误处理：error当做key。{“error”: “IOError”}

9、返回结果。具体有：

    get：/order：返回资源对象的列表（数组）

    get:  /order/1：返回单个资源对象的详细信息。

    post：/order： 返回新生成的资源对象。如果前端不需要，不需要返回，硬塞会浪费网络资源。

    put：/order/1： 返回完成的资源对象   

    patch：/order/1： 返回完成的资源对象

    delete：/order/1： 返回一个空文档

10、整体-局部：例如订单列表，那么为了方便，推荐增加成[{id:1, name:“a”, url:“http:www.baidu.com/1”},{…}]，即可以通过拿到这个URL访问到子数据的详细内容。

认识：restful本质只是一个规范，让我们在开发API的时候更好的编写和让前端更好记住URL，从而从URL体现出对API的操作。使用前也可以，但是比较臃肿，歧义多。使用后更简洁，意思更明确，但是也不是所有都采用，具体看功能业务的需要。例如新增post，推荐是返回新生成的对象，但是如果前端不需要则不返回。硬塞会浪费网络资源。通过规范，让协同开发的时候更加统一。

微信公众号：玩转测试开发
欢迎关注，共同进步，谢谢！