Retrofit踩坑之Delete请求 |
您所在的位置：网站首页 › 玉米粥手绘 › Retrofit踩坑之Delete请求 |
Retrofit踩坑之Delete请求
|
来到一家新的公司，时间直接不够用了，版本出的飞起，很长时间没总结自己最近学到的东西了（其实也没学什么）！ 公司的后台是一个搞php的大兄弟，我们进行对接。在对接的过程中，鄙人不才，一般都是用的POST和GET的请求居多，确实对DELETE请求接触不多，这次后台的大兄弟就直接让我提交DELETE请求来进行实体的删除操作。那就来呗，不就是和POST差不多嘛，代码如下： @DELETE("bean/delete") Observable daleteBean(@Query("id") String id); APIService.Retrofit().deleteBean(userId) .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(new BaseSubscriber(this) { @Override public void onNext(CommonBean commonBean) { //删除成功 } });结果是失败的，php的大兄弟说这样好像不对，应该是提交请求体。好！那就提交请求体 代码进行修改： @DELETE("bean/delete") Observable deleteBean(@Body DeleteUserBody body);这下算是请求体了吧，运行看结果
貌似是说这个框架不能包含@Body的注解，你妹啊！retrofit这么垃圾吗？看retrofit官网吧，根据我自己看完文档的理解@POST、@GET等注解其实也是演化的基础上来的， 其实他的原型是@HTTP(method = "POST", path = "/revoke", hasBody = false)，显然很明显 1、method ：请求方式 2、path ：路径 3、hasBody ：参数体 那就根据这个改一下呗 @HTTP(method = "DELETE", path = "location/delete", hasBody = true)数据提交成功，DELETE请求其实真的不是很常见，而一般的DELETE方式都是把参数拼接到PATH中进行提交，而我现在碰到的属于提交参数体，需求也是比较奇葩，所以在这里总结一下吧。
|
【本文地址】
今日新闻 |
推荐新闻 |