Retrofit Url 配置

如果你用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);  
}  

来自：http://blog.csdn.net/jdsjlzx/article/details/51354778

又如下面的：

 @GET("users/{user}/repos")
  Call<List<Repo>> listRepos(@Path("user") String user);

• 1
• 2

这些注解都有一个参数 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

这个用法需要服务器接口的配合。

补充：
http://blog.csdn.net/jdsjlzx/article/details/51607867

--------------------- 作者：一叶飘舟 来源：CSDN 原文：https://blog.csdn.net/jdsjlzx/article/details/51588605?utm_source=copy 版权声明：本文为博主原创文章，转载请附上博文链接！