正文开始之前，先说个折腾了2天才搞清楚的事情。
如果你用post请求进行提交数据（比如用户注册、登陆等表单类请求），参数类型一定要用准确，是Field，如果选择了Query，而调试过程没有发现这个问题，相信我你会发疯的。
@FormUrlEncoded
@POST("/some/endpoint")
Call<Response> register(@Field("name") String name);
@FormUrlEncoded
@POST("/some/endpoint")
Call<SomeResponse> someEndpoint(@FieldMap Map<String, String> names);
@FormUrlEncoded必须带上，防止出现乱码。
Retrofit 支持的协议包括 GET/POST/PUT/DELETE/HEAD/PATCH，当然你也可以直接用 HTTP 来自定义请求。这些协议均以注解的形式进行配置，比如我们已经见过 GET 的用法：
public interface IFamousInfo {
@GET("/avatardata/mingrenmingyan/lookup")
Call<FamousInfo> getFamousResult(@Header("apiKey") String apiKey,
@Query("keyword") String keyword,
@Query("page") int page,
@Query("rows") int rows);
}又如下面的：
@GET("users/{user}/repos")
Call<List<Repo>> listRepos(@Path("user") String user);这些注解都有一个参数 value，用来配置其路径，比如示例中的 users/{user}/repos，我们还注意到在构造 Retrofit 之时我们还传入了一个 baseUrl(“https://api.github.com/“)，请求的完整 Url 就是通过 baseUrl 与注解的 value（下面称 “path“ ） 整合起来的，具体整合的规则如下：
- path 是绝对路径的形式：
path = “/apath”，baseUrl = “http://host:port/a/b”
Url = “http://host:port/apath” - path 是相对路径，baseUrl 是目录形式：
path = “apath”，baseUrl = “http://host:port/a/b/”
Url = “http://host:port/a/b/apath” - path 是相对路径，baseUrl 是文件形式：
path = “apath”，baseUrl = “http://host:port/a/b”
Url = “http://host:port/a/apath” - path 是完整的 Url：
path = “http://host:port/aa/apath“，baseUrl = “http://host:port/a/b”
Url = “http://host:port/aa/apath”
建议采用第二种方式来配置，并尽量使用同一种路径形式。如果你在代码里面混合采用了多种配置形式，分分钟能出一堆 bug。
参数类型
发请求时，需要传入参数，Retrofit 通过注解的形式令 Http 请求的参数变得更加直接，而且类型安全。
Query & QueryMap（GET请求）
@GET("/list")
Call<ResponseBody> list(@Query("page") int page);Query 其实就是 Url 中 ‘?’ 后面的 key-value，比如：
http://www.baidu.com/?cate=android
这里的 cate=android 就是一个 Query，而我们在配置它的时候只需要在接口方法中增加一个参数，即可：
interface PrintlnServer{
@GET("/")
Call<String> cate(@Query("cate") String cate);
}如果有很多个Query，这么一个个写岂不是很累？而且根据不同的情况，有些字段可能不传，这与方法的参数要求显然也不相符。这时，容量更大的QueryMap 就是你最好的选择。
Field & FieldMap（POST请求）
其实我们用 POST 的场景相对较多，绝大多数的服务端接口都需要做加密、鉴权和校验，GET 显然不能很好的满足这个需求。使用 POST 提交表单的场景就更是刚需了，怎么做呢？
@FormUrlEncoded
@POST("/")
Call<ResponseBody> submit(
@Field("name") String name,
@Field("occupation") String occupation);
其实也很简单，我们只需要定义上面的接口就可以了，我们用 Field 声明了表单的项，这样提交表单就跟普通的函数调用一样简单直接了。
与Query一样，如果你有很多Field参数，不要怕，赶紧试试FieldMap吧。
Part & PartMap（POST请求）
这个是用来上传文件的。有了 Retrofit，妈妈再也不用担心文件上传费劲了~~~
public interface FileUploadService {
@Multipart
@POST("upload")
Call<ResponseBody> upload(@Part("description") RequestBody description,
@Part MultipartBody.Part file);
}如果你需要上传文件，和我们前面的做法类似，定义一个接口方法，需要注意的是，这个方法不再有 @FormUrlEncoded 这个注解，而换成了 @Multipart，后面只需要在参数中增加 Part 就可以了。也许你会问，这里的 Part 和 Field 究竟有什么区别，其实从功能上讲，无非就是客户端向服务端发起请求携带参数的方式不同，并且前者可以携带的参数类型更加丰富，包括数据流。
也正是因为这一点，我们可以通过这种方式来上传文件，下面我们就给出这个接口的使用方法：
在实验时，我上传了一个只包含一行文字的文件：
Visit me: http://www.println.net
那么我们去服务端看下我们的请求是什么样的：
HEADERS
FORM/POST PARAMETERS
description: This is a description
RAW BODY
最后放出一个绝招。
Retrofit2之“多个同名的查询参数”
如下链接：
https://api.stay4it.com/tasks?id=123
这个API例子只是返回id=123单个任务的response。
public interface TaskService {
@GET("/tasks")
Call<Task> getTask(@Query("id") long taskId);
}那么问题来了，如果有多个相同的id参数，怎么解决呢？
Multiple Query Parameters
我们需要请求的url就像下面那样
https://api.stay4it.com/tasks?id=123&id=124&id=125
我们预期返回的response是一个以url的ids=[123, 124, 125]为查询参数任务列表。
Retrofit通过提供一个ids的列表作为一个参数来执行一个含有多个同名参数的请求。Retrofit会一一对应给定的列表和多个同名参数。
public interface TaskService {
@GET("/tasks")
Call<List<Task>> getTask(@Query("id") List<Long> taskIds);
}@Body
这个用法需要服务器接口的配合。
@POST("/users/new")
Call<User> createUser(@Body User user);
}
