1楼：点点通软件公司
请求方式与请求路径，比较常见的请求方式是get与post，但在rest中又提出了几种其它类型的请求方式，汇总起来有六种：get、post、put、delete、head、options。尤其是前四种，正好与crud（create-retrieve-update-delete，增删改查）四种操作相对应，例如，get（查）、post（增）、put（改）、delete（删），这正是rest与crud的异曲同工之妙！
需要强调的是，rest是“面向资源”的，这里提到的资源，实际上就是我们常说的领域对象，在系统设计过程中，我们经常通过领域对象来进行数据建模。
rest是一个“无状态”的架构模式，因为在任何时候都可以由客户端发出请求到服务端，最终返回自己想要的数据，当前请求不会受到上次请求的影响。也就是说，服务端将内部资源发布rest服务，客户端通过url来访问这些资源，这不就是soa所提倡的“面向服务”的思想吗？所以，rest也被人们看做是一种“轻量级”的soa实现技术，因此在企业级应用与互联网应用中都得到了广泛应用。
下面我们举几个例子对rest请求进行简单描述：
可见，请求路径相同，但请求方式不同，所代表的业务操作也不同，例如，/advertiser/1这个请求，带有get、put、delete三种不同的请求方式，对应三种不同的业务操作。 虽然rest看起来还是很简单的，实际上我们往往需要提供一个rest框架，让其实现前后端分离架构，让开发人员将精力集中在业务上，而并非那些具体的技术细节。下面我们将使用java技术来实现这个rest框架，整体框架会基于spring进行开发。
4. 实现rest框架 4.1 统一响应结构 使用rest框架实现前后端分离架构，我们需要首先确定返回的json响应结构是统一的，也就是说，每个rest请求将返回相同结构的json响应结构。
不妨定义一个相对通用的json响应结构，其中包含两部分：元数据与返回值，其中，元数据表示操作是否成功与返回值消息等，返回值对应服务端方法所返回的数据。
对于前后端分离项目，还适合使用springmvc吗
2楼：萢萢
不知道你说的前后端分离
是指前后端有关系分开来开发
还是指前后端没有关系
如果是前后端有关系分开开发
spring mvc适合使用
如果前后端没有关系
可以考虑使用其它技术或方式实现
前后端如何做到分离开发，最后再整合部署
3楼：匿名用户
由于后端提供的接口方式可能多种多样，同时开发人员在编写node端**访问这些接口的方式也有可能多种多样。如果我们在接口访问方式及使用上不做统一架构处理，则会带来以下一些问题：
1. 每一个开发人员使用各自的**风格编写接口访问**，造成工程目录及编码风格混乱，维护相对困难。
2. 每一个开发人员编写自己的mock数据方式，开发完毕之后，需要手工修改**移除mock。
3. 每一个开发人员为了实现接口的不同环境切换(日常，预发，线上)，可能各自维护了一些配置文件。
4. 数据接口调用方式无法被各个业务model非常方便地复用。
5. 对于数据接口的描述约定散落在**的各个角落，有可能跟后端人员约定的接口文档不一致。
6. 整个项目分离开发之后，对于接口的联调或者测试回归成本依然很高，需要涉及到每一个接口提供者和使用者。
4楼：斋昌冒坚
搜一下：前后端如何做到分离开发，最后再整合部署
web项目开发为何要走前后端分离模式？
5楼：阿维子
我07年参加工作就是做企业级项目的开发，那时候的一些项目都只有一个包，没有什么**规范，业务逻辑散落在各处，甚至是jsp中直接访问数据库并做业务处理。
后来逐渐有了一些规范，页面就是页面，**就是**，很多项目开始使用ajax框架。
发展的更进一步，后端**有了分层，cotroller/service/dao，可能每个项目分层策略不同（三层和两层居多），每层的叫法不同（cotroller还是action），数据从页面到最后访问数据库，需要走到多个分层中。
不过到了此阶段，在企业级项目的开发过程中，java程序员依然要兼顾前后端的开发，所以前端页面的样子嘛，达不到美观的程度，也就是能用。
带来好处的同时，也会有一些缺点，例如：增加了架构的复杂性，如果技术能力不足的团队，可以考虑半分离（例如我们部门都是企业级应用，都没有前端开发人员）；如果是面向互联网的应用，需要搜索引擎抓取，就需要服务器端渲染；另外前后端交互的接口，也需要花时间和精力设计。
6楼：幽豆逗
毕竟只有前后端都走分离模式才可以促进这个项目的发展
7楼：哈哈哈
因为现在的前后端分离模式是非常高超的，利润度是非常的高的。
8楼：风蜂蜜柚子茶
因为只有前后端分离的模式才能适应这个项目的开发。
9楼：梦醒时分缘何为
因为只有这样这个项目才能够往前推进不是的吗
10楼：匿名用户
麻烦不要再搞什么前后端分离了好吧，后端人员写接口文档，对接口更痛苦了，反反复复改**，浪费时间，浪费精力。效率明明更差了
11楼：吹气球小男孩
那时候的一些项目都只有一个包，没有什么**规范，业务逻辑散落在各处，甚至是jsp中直接访问数据库并做业务处理。
12楼：萌萌不知道
把前端与后端独立起来去开发，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的**库，不同的开发人员，前后端工程师需要约定交互接口，实现同步开发
13楼：我是跳闸了
因为这就是未来发展的趋向的，所以才会这样的。
14楼：瓶盖缺塞儿
这个是为了更好的为生活和其他方面提供更好的帮助。
15楼：匿名用户
分为前端和后端有他自己的战略经营,是没有错的
如何在开发时部署和运行前后端分离的javawe
16楼：以道教育
在开发中大型的javaee项目时，前后端分离的框架逐渐成为业界的主流，传统的单机部署前后端在同一个项目中的工程项目越来越少。这类javaweb项目的后端通常都采用微服务的架构，后端会被分解为诸多个小项目，然后使用dubbo+zookeeper或者springcloud来构建微服务，前端则会是一个单独的项目，前台的请求通过微服务来调用。但是，不同与传统的web项目，这类前后端分离的项目如何在开发中部署和运行呢？
主要有两种方案：1.在本地通过nginx来处理这些静态资源。2、将静态资源统一放入一个javaweb应用中，并将自动生成的war包随后端项目一期丢入tomcat。下面详细介绍
一、使用nginx来访问静态资源。
在本地安装nginx并且修改nginx.conf，修改相关配置，将web访问的端口的资源进行更改，配置如下：
server
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css|woff|woff2|ttf|eot|map)$
listen对象改为你本地的tomcat访问端口，最下面location中的root改为你前端项目中静态资源的位置，这样就可以实现只部署后端的项目就能访问前端的页面了。
二、将前端项目转换为动态的web项目，随后端项目一起丢入tomcat
这个方案省去了在本地安装和配置nginx，但是也只适用于开发阶段项目的部署运行和调试，真正在生产环境通常前后端项目会部署在不同的服务器。
如果是eclipse，可以新建一个javaweb项目然后将静态资源放入web或者webcontent目录下，或者直接先导入前端项目，然后通过 project facts 将项目转换为dynamic web项目并勾选 js等相关配置。
然后，运行项目时把后端的war包和前端的war包一同添加到 deployment中运行即可。
17楼：建兰腾诗怀
前端和后台分离,不是完全分离,数据通道还有有的.不管是java或者.***都有后台向前端传送数据的方式
java前后端分离怎么做
18楼：匿名用户
表现层完全由前端掌控是最好的。所以掌握jsp和jstl是挺好的，等你全掌握之后麻利得把页面模板搞定就可以嘲笑后端都是bottleneck了。
当然不愿意用jsp/jstl之类的，也可以考虑完全用ajax，后端给http接口就好了。不过这种方式适应的应用形态略受限，比如非常要求seo的项目就不太好用。
19楼：小龙
可用最原始的servlet或者ssh s**框架
vue+springboot前后端分离如何部署项目？
20楼：请轻亲青草
最简单办法，vue编译完后的文件放到后端容器内
21楼：宁缺与静云
直接上**
github
22楼：匿名用户
https://blog.csdn.***/u013810234/article/details/89376466
https://blog.csdn.***/u013810234/article/details/89392732