Retrofit2.0学习第一弹——准备篇

本文主要是介绍Retrofit2.0学习第一弹——准备篇，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、Http简介

要想熟悉框架的使用，需要对一些基本的概念做一下了解，否则，有些地方理解的不好可能不好灵活的使用，主要涉及到了注解(Annotation),
HTTP协议,OkHttp,RESTful Api等，不可能一下子都能掌握，至少碰到某一部分，需要先做一下了解。当然，学过的同学可以略过，本人是非计算机专业的，所以需要补的东西很多哈。本篇文章主要是为学习Retrofit进行一下知识储备，对Http部分以及RESTful Api进行简单总结，这样后面在使用Retrofit处理接口参数时能理解的更加透彻些！

1.HTTP协议（HyperText Transfer Protocol，超文本传输协议）

HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等），Http以 ASCII 码传输，属于应用层传输。

原理：HTTP协议工作于客户端-服务端架构上，浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

2.URL和URI

HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。

对于URL和URI的区别，可以看下知乎上的回答，URI和URL区别。

实际中我们常用的网址是一个URL，URL可以说是URI的一种,URI—Uniform Resource Identifier 通用资源标志符,URL—Uniform Resource Location 统一资源定位符

http://127.0.0.1:8080/user?name=ralf

看下面一个示例图应该就明白了URL的组成了。

3. Http消息格式

消息分为请求和响应，格式大致相同。

HTTP请求

HTTP请求由三部分组成，分别是：请求行，消息报头，请求正文。

请求方法有 OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT 这几种。

示例

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

请求方法一行没什么说的，指明客户端操作，意义要访问的url，以及版本
在header部分，Content-Type说明消息主体部分的编码格式，post发送数据时需要在消息体中，服务端根据header中的编码格式来解析数据。格式可以自己定义，如果不指定，默认的表单格式为:

application/x-www-form-urlencoded

使用post方法时，会常常有上传文件的情况，这时就需要将格式指定为 multipart/form-data形式，此外，还有分割线，来分割不同的part，并且能够避免与header部分重复。

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

Http响应

与HTTP请求类似，HTTP响应也是由三个部分组成，分别是：状态行，消息报头，响应正文。

常见的状态行

• 200 - 请求成功

• 301 - 资源（网页等）被永久转移到其它URL

• 404 - 请求的资源（网页等）不存在

• 500 - 内部服务器错误

二、RESTful Api

1. Retrofit框架采用RESTful API

在RESTful架构中，每个网址代表一种资源（resource），所以网址中不含有动词，只有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的”集合”（collection），所以API中的名词也应该使用复数。

举例来说，有一个API提供动物园（zoo）的信息，还包括各种动物和雇员的信息，则它的路径应该设计成下面这样。

http://api.example.com/v1/zoos
http://api.example.com/v1/animals
http://api.example.com/v1/employees

2. 名词：

所谓的URL中使用名词，打个比方，以找某个地址为例，https://api.example.com可以理解为某栋楼的地址，然后需要有具体的单元、楼层，房间号、人名。
例如：

https://api.example.com/2/3/301/zhangsan

3. 动词：

动词不出现在URL中，但是也要说明请求的动作，那么在哪进行标识呢？RESTful Api 是基于Http提出的一套标准，那么它的动作也是和Http的动词是一样的，常用的也是增删改查。

4. 信息过滤

当请求的信息量很大时，就要进行筛选，那么如何筛选和过滤呢？下面举个例子来说明。

https://api.example.com/v1/employees?name=zhangsan&age=20
//查找员工，但并不想把所有的员工都拿出来，所以就选出符合 name=zhangsan和 age=20 的员工

5. 状态码

RESTful Api的状态码是和Http的状态码一致的。

6. 错误处理

如果状态码是4xx，就应该向用户返回出错信息。一般来说，返回的信息中将error作为键名，出错信息作为键值即可。

{error:"error information"
}

7. 返回结果

• GET /collection：返回资源对象的列表（数组）

• GET /collection/resource：返回单个资源对象

• POST /collection：返回新生成的资源对象
• PUT /collection/resource：返回完整的资源对象
• PATCH /collection/resource：返回完整的资源对象
• DELETE /collection/resource：返回一个空文档

参考

HTTP的POST提交的四种常见消息主体格式

菜鸟教程

RESTful API 设计指南

这篇关于Retrofit2.0学习第一弹——准备篇的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---