SpringBoot Controller接收参数的几种常用方式

第一类:请求路径参数
1、@PathVariable
获取路径参数。即url/{id}这种形式。

2、@RequestParam
获取查询参数。即url?name=这种形式

例子
GET
http://localhost:8080/demo/123?name=suki_rong
对应的java代码:

@GetMapping(“/demo/{id}”)
public void demo(@PathVariable(name = “id”) String id, @RequestParam(name = “name”) String name) {
System.out.println(“id=”+id);
System.out.println(“name=”+name);
}
1
2
3
4
5
输出结果:
id=123
name=suki_rong

第二类:Body参数
因为是POST请求,这里用Postman的截图结合代码说明

1、@RequestBody
例子

demo1

对应的java代码:

@PostMapping(path = “/demo1”)
public void demo1(@RequestBody Person person) {
System.out.println(person.toString());
}
1
2
3
4
输出结果:
name:suki_rong;age=18;hobby:programing

也可以是这样

@PostMapping(path = “/demo1”)
public void demo1(@RequestBody Map person) {
System.out.println(person.get(“name”));
}
1
2
3
4
输出结果:
suki_rong

2、无注解
例子

demo2

对应的java代码:

@PostMapping(path = “/demo2”)
public void demo2(Person person) {
System.out.println(person.toString());
}
1
2
3
4
输出结果:
name:suki_rong;age=18;hobby:programing

Person类
public class Person {

private long id;
private String name;
private int age;
private String hobby;

@Override
public String toString(){
    return "name:"+name+";age="+age+";hobby:"+hobby;
}

// getters and setters

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
第三类:请求头参数以及Cookie
1、@RequestHeader
2、@CookieValue
例子
java代码:

@GetMapping(“/demo3”)
public void demo3(@RequestHeader(name = “myHeader”) String myHeader,
@CookieValue(name = “myCookie”) String myCookie) {
System.out.println(“myHeader=” + myHeader);
System.out.println(“myCookie=” + myCookie);
}
1
2
3
4
5
6
也可以这样

@GetMapping(“/demo3”)
public void demo3(HttpServletRequest request) {
System.out.println(request.getHeader(“myHeader”));
for (Cookie cookie : request.getCookies()) {
if (“myCookie”.equals(cookie.getName())) {
System.out.println(cookie.getValue());
}
}

}

作者:suki_rong
来源:CSDN
原文:https://blog.csdn.net/suki_rong/article/details/80445880
版权声明:本文为博主原创文章,转载请附上博文链接!

最近2周我把市面上 快速开发平台又看了一遍

最近2周我把市面上 快速开发平台又看了一遍,真的太复杂了,不实用,不仅不能快速开发,如果你真的在他们上面开发:

1)不是一个人能搞定的,光是前后端分离,无论是Vue还是 React,都得2-3个前端才能搞定了;后端Spring Cloud系列+JWT+权限+Nacos/Consul,也不是1个人能轻松搞定的,也得需要3-4个人

2)先得学习很多新东西

3)不见得能紧贴自己项目,所以这是一个轮子又一个轮子造出来的原因

。。。

Spring cloud Gateway与Consul 与Nacos踩的坑

采用Spring gate的时候,服务注册与发现,到底是用Consul还是Nacos?先是用Consul尝试了一下,发现用Spring boot编写的微服务,一定要与Consul在同一台机器上,Consul不支持远程注册(不知道是个不是与我用的参数-dev模式有关,仅支持127.0.0.1的服务注册);遂放弃,有试了试Nacos,Nacos到是很惊喜的支持Spring boot编写的Service与其不在同一台机器上,但是坑又来了

nacos现在选的版本是0.8,nacos在

routes:
– id: bi-admin
uri: lb://bi-admin

仅仅支持http协议,不支持lb协议,尝试了很久,gateway没转发到Springboot编写的service ,久久不能释怀,遂又改回Consul,一下又成功了。

第二天不甘心,又开始折腾Nacos,Spring cloud gateway和nacos环境时好时坏,只好从网上下载nacos.io 原始实例,在原始实例上调试,居然调通了gateway–> nacos –>Spring boot Service provider ,还是非常高兴的

如何修改 WordPress 5.0 ReadMore 为“阅读全文”

以前都是在Centos+Nginx/Apache+Php 环境下安装WordPress,但是我其实根本不熟悉Linux,连二把刀也算不上,但是基本环境按照网上教程也都能配置好,包括Java/Tomcat/MySQL环境,所以也一直在Linux服务器下工作,好多个月不重启,也没任何事情。

由于客户的环境是Oracle,实在担心自己在Linux下安装Oracle不顺利,所以就购买了华为云的Windows 2000 R2环境的服务器。安装Oracle倒是挺顺利的,但是安装Php环境,遇到了很多坑。

关于WordPress中的 ReadMore修改为“阅读全文”,网上也有很多文档,但不是过时了,就是无效,我翻来翻去,在 \wp-content\themes\adventure-travelling\template-parts\post 目录下,看到了content.php这个文件,打开后看到了

esc_attr_e( ‘ReadMore’, ‘adventure-travelling’ )和 esc_html_e(‘ReadMore’,’adventure-travelling’),把这个
ReadMore 修改为“阅读全文”,文件编码格式另存为UTF-8,重新打开,“ReadMore”就变成了“阅读更多”

adventure-travelling 是我用的一个一个模板。

什么是前置仓

永辉生活近日在福州试点前置仓模式来管理线下业务,那么这个前置仓模式是什么,与后置仓模式区别在于哪里?

的盒马鲜生所采取的仓配模式。它的每个门店都是一个中小型的仓储配送中心,这使得总部中央大仓只需对门店供货,也能够覆盖最后一公里。消费者下单后,商品从附近的零售店里发货,而不是从远在郊区的某个仓库发货。这便是支撑它在门店3公里范围内可以做到30分钟送达的重要前提。

“沃尔玛和亚马逊的可移动仓库好比一种更为极致的前置仓模式,它把仓库建在空中,距离客户更近了。你下单之后,无人机会选择最快捷的路径把商品运送给你,全程无阻碍、耗能低。”

在空中漂浮着的可移动仓库配上无人机,不仅解决了最后一公里的距离问题,也解决了仓库的空间问题,以及物流运输途中的交通问题。

在冷链物流服务中,最难的部分就是“最后一公里”配送。据陈锐介绍,先发国家和地区早有生鲜产品的配送服务,如日本和台湾采取的是“宅配”的服务模式,即生鲜产品销售方通过冷链物流(如冷藏车运输)直接将产品配送至客户家中。

在我国,也存在这种冷链物流服务,一般情况是在生鲜电商平台自配体系中,商家会在特定区域、特定时段、针对特定产品进行冷链“宅配”。由于产品直接从商家城市中心仓直发至最终客户手中,一般称之为“中心仓”模式。这种模式对生鲜产品品质保护更好,但是运营成本高,并且受到诸多限制。同时,由于我国市场的特殊情况,这种冷链物流服务目前并不是主流的冷链物流服务模式,主要有两个原因:第一,中国城市交通管制和停车设施等问题,使得冷藏车很难在白天在城市通行,因此很难为个人客户提供上门配送服务;第二,中国城市人口密度大,电商规模更大,生鲜电商订单数量也远超日本和台湾地区,消费者对订单响应速度要求更高,这都使得这种宅配模式无法满足中国生鲜电商的发展需求。

目前我国企业更普遍采用的冷链物流模式是“泡沫箱+冷袋”的模式。用“泡沫箱+冷袋”把生鲜产品打包成一个包裹,包裹内部形成适合生鲜产品保存的局部空间,包裹在物流运作时被视为普通包裹,走现有常温物流配送体系。这种模式成本较低,但是对生鲜产品的品质保护难以保证,对冷链环境要求特别高的生鲜产品无法用这种物流服务模式。

而前置仓模式,是指更靠近消费者的小型仓储单位,一般设置在消费者集中的社区附近。其运营模式是:生鲜产品销售方利用冷链物流(冷藏车)提前将产品配送至前置仓存储待售,客户下单后,由前置仓经营者组织完成包裹生产和“最后一公里”的上门配送。无论是订单响应速度还是配送成本,前置仓模式相比直接配送都具有很大优势。

而在现代零售环境当中,仓库的前置变得越来越重要。简单说就是把仓库设在离消费者更近的地方,可能是某个办公楼,可能是某个社区,也可能是直接把零售门店附以仓库功能,用户下单后,能够尽可能在最短的距离和时间内送货上门。