我想请教下各位前辈，前端用PHP，后端用Java，怎么进行交互额？
AJAX的话可以用JSON
可是如果只是页面跳转的话，用啥额，PHP不可能懂得SpringMVC吧
前端用PHP，后端用java的话，由java提供相关的接口就可以了啊，用curl请求接口信息。
1、可以使用http的方式进行RPC（这也是最基础的方式啦）
2、利用yac等RPC框架（虽然也是基于HTTP的，但是反序列化和序列化会更爽）。
3、使用RabbitMQ等队列。
4、socket。。。。。。（这个比较底层，如果你对连接有特殊需求的话，建议自定义化，当然会复杂以及难度变大）
前端php。。。真够纠结的，谁这样设计的。。2个语言随便哪个都行了。
交互方式多了，http、socket、rpc，随便选吧
这种情况下，用 Hprose 是个不错的选择。
关于 REST 介绍的文章已经很多了，这里只对 RPC 部分做一个介绍：
RPC(远程过程调用)是什么
- 简单的说，RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
- RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
- RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
- RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。
远程过程调用发展历程
- ONC RPC （开放网络计算的远程过程调用），OSF RPC（开放软件基金会的远程过程调用）
- CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）
- DCOM（分布式组件对象模型），COM+
- Java RMI
- .NET Remoting
- XML-RPC，SOAP，Web Service
- PHPRPC，Hessian，JSON-RPC
- Microsoft WCF，WebAPI
- ZeroC Ice，Thrift，GRPC
- Hprose
早期的 RPC
- 第一代 RPC（ONC RPC，OSF RPC）不支持对象的传递。
- CORBA 太复杂，各种不同实现不兼容，一般程序员也玩不转。
- DCOM，COM+ 逃不出 Windows 的手掌心。
- RMI 只能在 Java 里面玩。
- .NET Remoting 只能在 .NET 平台上玩。
XML-RPC，SOAP，WebService
- 冗余数据太多，处理速度太慢。
- RPC 风格的 Web Service 跨语言性不佳，而 Document 风格的 Web Service 又太过难用。
- Web Service 没有解决用户的真正问题，只是把一个问题变成了另一个问题。
- Web Service 的规范太过复杂，以至于在 .NET 和 Java 平台以外没有真正好用的实现，甚至没有可用的实现。
- 跨语言跨平台只是 Web Service 的一个口号，虽然很多人迷信这一点，但事实上它并没有真正实现。
PHPRPC
- 基于 PHP 内置的序列化格式，在跨语言的类型映射上存在硬伤。
- 通讯上依赖于 HTTP 协议，没有其它底层通讯方式的选择。
- 内置的加密传输既是特点，也是缺点。
- 虽然比基于 XML 的 RPC 速度快，但还不是足够快。
Hessian
- 二进制的数据格式完全不具有可读性。
- 官方只提供了两个半语言的实现（Java，ActionScript 和不怎么完美的 Python 实现），其它语言的第三方实现良莠不齐。
- 支持的语言不够多，对 Web 前端的 JavaScript 完全无视。
- 虽然是动态 RPC，但动态性仍然欠佳。
- 虽然比基于 XML 的 RPC 速度快，但还不是足够快。
JSON-RPC
- JSON 具有文本可读性，且比 XML 更简洁。
- JSON 受 JavaScript 语言子集的限制，可表示的数据类型不够多。
- JSON 格式无法表示数据内的自引用，互引用和循环引用。
- 某些语言具有多种版本的实现，但在类型影射上没有统一标准，存在兼容性问题。
- JSON-RPC 虽然有规范，但是却没有统一的实现。在不同语言中的各自实现存在兼容性问题，无法真正互通。
Microsoft WCF，WebAPI
- 它们是微软对已有技术的一个 .NET 平台上的统一封装，是对 .NET Remoting、WebService 和基于 JSON 、XML 等数据格式的 REST 风格的服务等技术的一个整合。
- 虽然号称可以在 .NET 平台以外来调用它的这些服务，但实际上跟在 .NET 平台内调用完全是两码事。它没有提供任何在其他平台的语言中可以使用的任何工具。
ZeroC Ice，Thrift，GRPC
- 初代 RPC 技术的跨语言面向对象的回归。
- 仍然需要通过中间语言来编写类型和接口定义。
- 仍然需要用代码生成器来将中间语言编写的类型和接口定义翻译成你所使用的编程语言的客户端和服务器端的占位程序（stub）。
- 你必须要基于生成的服务器代码来单独编写服务，而不能将已有代码直接作为服务发布。
- 你必须要用生成的客户端代码来调用服务，而没有其它更灵活的方式。
- 如果你的中间代码做了修改，以上所有步骤你都要至少重复一遍。
Hprose
- 无侵入式设计，不需要单独定义类型，不需要单独编写服务，已有代码可以直接发布为服务。
- 具有丰富的数据类型和完美的跨语言类型映射，支持自引用，互引用和循环引用数据。
- 支持众多传输方式，如 HTTP、TCP、Websocket 等。
- 客户端具有更灵活的调用方式，支持同步调用，异步调用，动态参数，可变参数，引用参数传递，多结果返回（Golang）等语言特征，Hprose 2.0 甚至支持推送。
- 具有良好的可扩展性，可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
- 兼容的无差别跨语言调用
- 支持更多的常用语言和平台
- 支持浏览器端的跨域调用
- 没有中间语言，无需学习成本
- 性能卓越，使用简单
来点实用的：https://github.com/guzzle/guzzle
后端的话 直接请求连接嘛 , 如果跳转需要带参数就ajax值写入连接里面
很有意思，我曾经也是老大让我做过这个调研，当时还用php与java结合做了一个项目。看到这里前面的回答，大部分都是说通过RESTfull API或json去调用java处理业务逻辑的结果，而我想题主可能更需要的是Quercus、PHP/Java Bridge或SOAP这三种技术的一种。
Quercus是一个完全以java实现的PHP5引擎，可以让PHP程序在JVM上执行，前端php代码就像引入java包一样，然后就可以直接new一个java对象来使用。这也是我在调研项目中选用的。
PHP/Java Bridge 本质上也是通过XML去前后端交互数据的，但是它实现的PJB协议不需要我们自己去解析XML获取数据，php-java-bridge帮我们做好了数据类型映射这类功能。
SOAP具有与程序语言、平台和硬件无关的特性，不仅可以引用于php和java之间，但是据说效率不怎么高。
实际测试结果，个人真觉得没必要把一个项目用这种实现方法，一个字，zuo。
有了上面这些信息，我相信谷歌可以告诉你更多。
目前我公司就是这种架构，但是也不是说让php只负责前端，跟淘宝UED的那篇文章，多少有点出入。php当然可以只负责前端来调用java数据接口。但是也可以去负责一些php擅长的逻辑。
java负责大数据的处理之类的。从业务上与PHP分离开。
楼主的问题是如何交互，@seanlook 说的几种方式，比较完整了。大致就是webservice、RPC，soap这几种方式。用java虚拟机跑php，我觉得要比rpc调用会坑很多。
我们公司是用的RPC，但是是自己实现的RPC框架，数据转为二进制的，使用google 的 protobuffer。
rpc调用也很方便。几行代码就搞定了。因为数据传输使用二进制，所以效率上是比soap之类的快。应该是最优的选择了。希望能帮到题主。
更新！
我去，没仔细看楼主的问题，原来只是要交互啊，最简单的，如果你用springmvc，那么你直接把action作为接口暴露出来，php发起http请求调用java的接口就哦了~！
java只暴露api，然后php拿到json数据，渲染页面，页面跳转放到php呢？
突然想起来之前看到过淘宝ued的一篇文:
前后端分离
主要思想也就是酱紫吧：
前端：负责View和Controller层。
后端：只负责Model层，业务处理/数据等。
文中前端是:node+js+html
你换成：php+js+html
然后看到楼下说的rpc，也不是很懂，就查了一下，可以看这个回答理解一下：
什么是RPC
对应的就可以用php的rpc框架了，比如yar，当然不用也是可以的吧
php不是用来做后端程序的吗？
有必要用java嘛，PHP是世界上最好的语言，并且PHPNG 也快出来了
基本就是 http+json.当然也可以使用现成的rpc框架