请求参数从传递方式可分三种：url参数，请求主体以及表单编码。我们来一一讨论。
url参数就是在url链接后面的键值对，例如 https://api.weibo.com/2//statuses/public_timeline.json?access_token=xxx 中，access_token就是url参数，xxx为其值。
Retrofit定义url参数非常直接，只要在方法参数前面添加@Query("key")注解即可。@Query中key的值与url中的参数名称是一致的，Retrofit会自动添加这些参数到url中。
以之前获取微博公共动态的API为例，具体API详见 http://open.weibo.com/wiki/2/statuses/public_timeline 。从接口中看到，必选参数只有access_token一个，我们定义个方法如下：
方法timelineForPublic需要参数token，Retrofit会通过@Query中定义的名称access_token将token映射成请求参数access_token。此时，请求url就会变成：
从获取微博公共动态的API中我们可以看到，除了必选的access_token，还有三个可选参数count、page以及base_app，也就是说现在请求参数有四个了。有了上面定义请求参数的介绍，我们只需要往方法上添加相应的参数并用@Query进行注解：
此时，如果我们只需要传递access_token，而不需要其他参数，则可以在调用方法的时候传null。当然，我们不能传null给int这样的原生类型，而需要使用对应的Integer。而Retrofit会跳过值为null的参数，并在组装请求的时候忽略它们。
获取公共微博最多有四个参数，那么我们再查看下获取好友微博API http://open.weibo.com/wiki/2/statuses/friends_timeline ，发现其有一个必选参数以及七个可选参数，也就是方法会有八个参数。那么问题来了，如果有更多的可选参数，那方法的参数是不是也会特别多，而且很多时候我们只需要其中一两个请求参数，却需要提供所有的参数值，显然很繁琐。为了处理这种情况，QueryMap就该登场了。
我们可以使用下面的方式定义获取公共微博API的方法：
@QueryMap后面需要紧跟着一个Map<String, String >类型，这样就可以动态地添加查询参数了。如果说只需要accept_token参数，则可以像下面这样调用：
这样，我们只需要传递我们需要设置的参数就可以了。
在我们查看微博的各个API时，会发现每个请求都需要一个access_token参数，于是我们就在所有的方法中都添加了对应的参数。那么有没有简单的方式来给每个请求都添加相同的参数，从而不需要每个请求都做相同处理呢？
强大的Retrofit是支持的，但是是通过OkHttp中的拦截器来实现的。我们在 《Retrofit之初体验》 提及过，Retrofit直接依赖OkHttp，使用OkHttp作为底层网络客户端。而使用OkHttp可以添加拦截器，用来修改即将发出去的请求，这个可以参见 《OkHttp之拦截器》 。这样我们就可以在拦截器中，对每个请求添加一个access_token参数了：
首先获取到了HttpUrl对象，然后基于原始的HttpUrl对象创建一个新的构建器，从而可以使用addQueryPatameter()方法添加额外的查询参数，最后将这个新的HttpUrl对象通过Request.Builder方法设置到Request中。
在我们实际应用中，大多数时候会通过请求主体向服务器发送数据。以我们的惯例，都会以微博API为例，但可惜的是并没有找过微博使用这种方式的API，而都使用的是表单方式，这个会在后面讨论。所以个很常见的例子，那就是登陆，通常请求参数如下：
好的，登录的方法定义如下：
其中LoginParam.java类如下：
首先，我们使用了@Body注解了方法参数，而我们在创建Retrofit.Builder的时候也为其添加了GsonConverter转换器。
这样，Retrofit会将LoginParam对象转换为Json，并将其作为主体数据添加到请求中，支持了使用请求主体向服务器发送数据。
在上面我们使用了用请求主体的方式来向服务器发送数据，除了这种方式，还可以通过表单编码(form-urlencoded)的形式。微博API中的写入接口都是采用这种方式向服务器发送数据的，我们这里以转发微博为例，具体API详见 http://open.weibo.com/wiki/2/statuses/repost 。
首先，定义转发微博的方法：
我们看到了@FormUrlEncoded注解，这个注解不能使用在GET请求上，因为它代表要想服务器发送数据。此外，在参数id上使用@Field注解，表示请求会发送此参数到服务器，而@Field("id")中的id则定义的是参数名称。
与@Query类似，当你有多个参数要发送时，只需要使用@Field注解它们即可。同样与@QueryMap对应的有个@FieldMap注解，具体使用类似。
@Field与@FieldMap都有一个属性encoded，表示键值对是否进行url编码，默认为false。以@Field为例，使用如下：
了解完@Field之后，我们讨论下表单编码与url参数的区别：表单编码使用在POST请求中的，而url参数是用在GET请求中的。表单编码使用请求主体发送数据到服务器，而不是url参数。而url参数的使用主要是为了从服务器过滤或者获取指定的数据。
Ok，本文就讨论到这里，感谢大家的阅读，下文我们将讨论Retrofit如何定义请求头。
如果你对retrofit感兴趣，同时你也觉得我的文章可以给你带来那么一丢丢的帮助，敬请关注，后续会继续介绍Retrofit的相关使用。
源码地址：
https://github.com/FILWAndroid/DevJourney
关于源码：
提前声明，以下提到的方案并没有去验证过可行性，只是记录一下，未来需要用到的时候，在仔细验证一下。
一般情况下，各个公司的移动端关于登录令牌(token)的设定都各不相同。
可先参考这个链接： https://www.zhihu.com/question/30267006
了解一下，本文大概想说什么。
有些公司服务端是按照oauth设计，比较标准规范，但是有些公司有自己的特定业务，未完全按照oauth来设计。基于本公司的业务逻辑，考虑了一下登录的逻辑以及token的设计。
思路如下：
token即验证令牌，每次请求都带上，refreshToken用来刷新token的，每次请求可以不带上，但是要放在移动端保存。
1.通过username，password获取token和refreshToken
2.token的有效期为2小时，refreshToken的有效期为15天
3.如果服务器端判断token过期，而refreshToken未过期，就返回错误码给客户端，则客户端通过一个特定的接口传入refreshToken参数获取新的token和refreshToken
4.如果连续15天未使用app或者用户修改了密码，则表示refreshToken过期了，则跳到登录界面，重新登录获取token和refreshToken
基于上面的思路，如果服务端走rest风格，移动端（Android）采用retrofit(v2.0+)+okhttp(v2.7.0+)网络请求框架。那么当token过期了，Android端应该如何处理呢？
通过okhttp提供的Authenticator接口，相关资料 点击这里 ，但是查看okhttp的源码会发现，只有返回HTTP的状态码为401时，才会使用Authenticator接口，如果服务端设计规范，可以尝试如下方法。
实现Authenticator接口
然后给添加给OkHttpClient
第一种方案就这样了。
但是，万事不会尽如人意，如果服务端在token过期的时候，不给返回401的HTTP状态码，而是返回如下类型的数据，叫你根据code判断。
这里要清楚HTTP状态码是指200，404，401这些，而上面的数据中的code是自定义的。如果在token过期时，服务端返回的是如上类型的数据，那么第一种方案就行不通。
通过okhttp的拦截器，okhttp 2.2.0 以后提供了拦截器的功能，相关介绍 点击这里
然后给okhttp设置拦截器
第二种方案的思路是通过拦截返回的数据，判断token是否过期，如果过期则进行一次刷新token的 *** 作。
上面2种方案都没有进行实际验证过，希望以后有机会能验证。
完。。。
题：在此默认各位看官对Retrofit、以及Okhttp已经有过一定的了解及应用，所以今天我们不谈基础入门的东西，今天我们谈在Retrofit请求接口管理类中URL参数含有动态参数的处理方式。一般我们使用Retrofit大部分场景中URL都是以注解的方式静态声明的，即URL及path路径都是固定不变，可变部分作为方法的参数传入，那有一些特殊情况会要求我们再使用@GET()、或者@POST()的时候URL路径里含有可变参数，需要动态处理，下面通过例子我逐个为大家分析讲解。
2.) url中含有参数
3.)可变参数在URL的问号之后
4.) 问号后面有多个参数 :
5.)问号后面有多个参数，且参数个数不定
2.POST请求
2.) url中含有可变参数、问号之后需要加入token，post的数据只有一个type
3.) url中含有可变参数、问号之后需要加入token，post的数据为一个对象（json串）
以上内容 转自： https://blog.csdn.net/xieluoxixi/article/details/80092582
另外还有几点
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）