phprestapi

Ⅰ php和jsp哪个好，有人说PHP快被淘汰了

你用的网络知道就是用php写的后台，腾讯网络的主要平台都是php编码，你觉得快被淘汰了么？
技术总是在不断发展，jsp才是有可能被淘汰的，基于mvc的框架下，前端有太多的替代品。
而PHP和JAVA很明显短期内是不会被淘汰的，新的语言规范也一直在发展，二十年前的VB现在依然有系统在使用，PHP面向网站开发，快速高效，JAVA则更多倾向于系统开发，性能强大且稳定，他们的特点不被完全替代，就永远不会被淘汰。
目前发展趋势更多是在原有基础上针对不同需求使用不同语言开发针对性的模块，如Node.js的高效REST API，在I/O上有巨大优势，但并未广泛应用。
语言更像是瑞士军刀上的各种工具，没有非谁不可。实际上被淘汰的永远只有不愿进步的程序员

Ⅱ PHP网站提供API服务

网站上的API接口就是在别的网站上使用一组代码,调用提供接口网站的内容,如一个普通的iframe嵌入式框架代码可以显示一个网站提供的工具,别的网站通过添加这个代码,就可以在自己的网站上使用显示这个工具,如http://www.into123.cn

Ⅲ php根据经纬度获取地理位置

这种功能，只能调用第三方的接口了，网络地图API就有这个接口addressComponents，逆地址解析，参考方法如下：

<GeocoderSearchResponse>

<status>OK</status>

<result>

<location>

<lat>38.990998</lat>

<lng>103.645966</lng>

</location>

<formatted_address>甘肃省武威市民勤县</formatted_address>

<business/>

<addressComponent>

<streetNumber/>

<street/>

<district>民勤县</district>

<city>武威市</city>

<province>甘肃省</province>

</addressComponent>

<cityCode>118</cityCode>

</result>

</GeocoderSearchResponse>

Ⅳ php rpc好用吗,有什么优缺点php rpc框架哪个好

什么是RPC框架？ 如果用一句话概括RPC就是：远程调用框架（Remote Procere Call）那什么是远程调用？通常我们调用一个php中的方法，比如这样一个函数方法: localAdd(10, 20)，localAdd方法的具体实现要么是用户自己定义的，要么是php库函数中自带的，也就说在localAdd方法的代码实现在本地，它是一个本地调用！远程调用意思就是：被调用方法的具体实现不在程序运行本地，而是在别的某个远程地方。

远程调用原理

比如 A (client) 调用 B (server) 提供的remoteAdd方法：

• 首先A与B之间建立一个TCP连接；

• 然后A把需要调用的方法名（这里是remoteAdd）以及方法参数（10， 20）序列化成字节流发送出去；

• B接受A发送过来的字节流，然后反序列化得到目标方法名，方法参数，接着执行相应的方法调用（可能是localAdd）并把结果30返回；

• A接受远程调用结果,输出30。

RPC框架就是把我刚才说的这几点些细节给封装起来，给用户暴露简单友好的API使用。

远程调用的好处

解耦：当server需要对方法内实现修改时，client完全感知不到，不用做任何变更；这种方式在跨部门，跨公司合作的时候经常用到，并且方法的提供者我们通常称为：服务的暴露。

RPC与Socket有什么区别？

通过上面的简单阐述，好像RPC与Socket 好像啊。都是调用远程的方法，都是client/server模式，我之前也写了一篇文章: 细说socket 那他们有啥区别呢?

RPC（远程过程调用）采用客户机/服务器模式实现两个进程之间相互通信。socket是RPC经常采用的通信手段之一，RPC是在Socket的基础上实现的，它比socket需要更多的网络和系统资源。除了Socket，RPC还有其他的通信方法，比如：http、操作系统自带的管道等技术来实现对于远程程序的调用。微软的Windows系统中，RPC就是采用命名管道进行通信。

RPC与REST有什么区别？

通过了解RPC后，我们知道是RPC是client/server模式的，调用远程的方法，REST也是我们熟悉的一套API调用协议方法，它也是基于client/server模式的，调用远程的方法的，那他俩又有啥区别呢？

REST API 和 RPC 都是在 Server端 把一个个函数封装成接口暴露出去，以供 Client端 调用，不过 REST API 是基于HTTP协议的，REST致力于通过http协议中的POST/GET/PUT/DELETE等方法和一个可读性强的URL来提供一个http请求。而 RPC 则可以不基于 HTTP协议
因此，如果是后端两种语言互相调用，用 RPC 可以获得更好的性能（省去了 HTTP 报头等一系列东西），应该也更容易配置。如果是前端通过 AJAX 调用后端，那么用 REST API 的形式比较好（因为无论如何也避不开 HTTP 这道坎）。

php中流行的rpc框架有哪些

既然php是世界上最好的语言，那php中流行的RPC框架有哪些呢？

先列举下： phprpc，yar, thrift, gRPC, swoole, hprose

因为时间和精力有限，不可能一个一个的去学习和使用，我选几个世面上用的最多的几个用下吧。因为RPC原理是一样的，都是Client/Server模式，只是每个框架的使用方式不一样而已。

Ⅳ wordpress使用api

      WordPress REST API (Version 2)       访问外部api的插件

     JWT Authentication for WP REST API    需要外部访问的插件(安装之后，外部可以访问token)

        第一步：内部设置，需要找到 . htaccess文件，在这里面写

                 RewriteEngine on

                  RewriteCond %{HTTP:Authorization} ^(.*)

                  RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]

                  SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

          第二步：需要找到 wp-config.php 文件，写入

                   define('JWT_AUTH_SECRET_KEY', 'your-top-secret-key');

Ⅵ 有PHP版的 word在线编辑器么

需求是原生的Word在线编辑，还是就是文本编辑。如果是文本编辑，那选择方案就很多了，随便找个H5的编辑工具。
如果是原生的Word在线编辑，一般来说两种途径。一种是利用插件，比如PageOffice，就支持PHP。好处是服务端有一整套的开发接口，劣势是需要安装插件，客户端需要有Word应用程序安装，不同的客户端环境不同可能造成后继使用过程中的维护量。
还有一种是无插件的方式，Office 365就是典型的，不过如果是私有化部署，就不能用Office 365了。还有一个是uzer.me，能提供无插件的原生Word编辑，提供JS SDK和REST API，PHP也能对接。好处是无插件，劣势是只支持webRTC的浏览器，比如火狐、谷歌，360极速等，反正IE是不支持的。

Ⅶ php做api接口给手机应用获取数据

不是的，通常php查询数据库，取得结果集后，把每行的每个字段值作为一个节点输出xml，或者把所有行数据存入一个数组，之后json_encode输出json供app调用。

Ⅷ 什么是RESTful风格的API

REST -- REpresentational State Transfer
首先，之所以晦涩是因为前面的主语被去掉了，全称是 Resource Representational State Transfer，通俗来讲就是：资源在网络中以某种表现形式进行状态转移。

分解开来：
Resource：资源，即数据（前面说过网络的核心）。比如 newsfeed，friends等；
Representational：某种表现形式，比如用JSON，XML，JPEG等；
State Transfer：状态变化。通过HTTP动词实现。

大家都知道“古代”网页是前端后端融在一起的，比如之前的PHP，JSP等，在之前的桌面时代，前后端融合在一起没啥问题，但是近年来移动互联网的发展，各种类型的Client层出不穷，RESTful可以通过一套统一的接口为Web、iOS、Android、小程序等提供接口API服务。另外对于广大平台来说，比如Facebook platform，微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口，于是RESTful的API更是它们最好的选择。

根据Richardson Maturity Model（理乍得森成熟度模型）, REST架构的成熟度有4个等级：

我们在咖啡店向前台点了一杯拿铁咖啡，这个过程可以用这段文字来描述：

我们通过这段文字告诉前台，新增一笔订单，订单是一杯拿铁咖啡，接着，前台给我们返回这么一串回复：

假设我们有一张会员卡，我们想查询一下这张会员卡的余额，这时候要向前台发起另一个询问：

查询卡号为447031335的卡的余额，查询的结果返回来了：

没钱……哈哈哈，没钱，现在我们要跟前台说，这杯咖啡不要了：

现在这家咖啡店越做越大，来喝咖啡的人越来越多，单靠前台显然是不行的，店主决定进行分工，每个资源都有专人负责，我们可以直接面向资源操作。
比如还是下单，请求的内容不变，但是我们多了一条消息:

多了一个斜杠和orders，这是什么意思？
这个表示我们这个请求是发给哪个资源的，订单是一种资源，我们可以理解为是咖啡厅专门管理订单的人，他可以帮我们处理所有有关订单的操作，包括新增订单、修改订单、取消订单等操作。
接着还是会返回订单的编号给我们：

下面，我们还是要查询会员卡余额，这次请求的资源变成了cards：

接下来是取消订单：

接下来，店主还想继续优化他的咖啡厅的服务流程，他发现负责处理订单的员工，每次都要去订单内容里面看是新增订单还是删除订单，还是其他的什么操作，十分不方便，于是规定，所有新增资源的请求，都在请求上面写上大大的“POST”，表示这是一笔新增资源的请求。
其他种类的请求，比如查询类的，用‘GET’表示，删除类的，用‘DELETE’表示，修改用PATCH表示。
来，我们再来重复上面那个过程，来一杯拿铁：

请求的内容简洁多啦，不用告诉店员是addOrder，看到POST就知道是新增，返回的内容还是一样：

接着是查询会员卡余额，这次也简化了很多：

这个请求我们还可以进一步优化为这样：

直接把要查询的卡号写在后面了。
没错，接着，取消订单：

忽然有一天，有个顾客抱怨说，他买了咖啡后，不知道要怎么取消订单，咖啡厅一个店员回了一句，你不会看我们的宣传单吗，上面不写着：

顾客反问道，谁会去看那个啊，店员不服，又说到，你瞎了啊你……后面两人吵着吵着还打了起来…
噗，真是悲剧…

有了这次教训，店长决定，顾客下了单之后，不仅给他们返回订单的编号，还给顾客返回所有可以对这个订单做的操作，比如告诉用户如何删除订单。现在，我们还是发出请求，请求内容和上一次一样：

但是这次返回时多了些内容：

这次返回时多了一项link信息，里面包含了一个rel属性和url属性，rel是relationship的意思，这里的关系是cancel，url则告诉你如何执行这个cancel操作，接着你就可以这样子来取消订单啦：

哈哈，这服务真是贴心，以后再也不用担心店员和顾客打起来了。
Level 3的Restful API，给使用者带来了很大的便利，使用者只需要知道如何获取资源的入口，之后的每个URI都可以通过请求获得，无法获得就说明无法执行那个请求。
现在绝大多数的RESTful接口都做到了Level2的层次，做到Level3的比较少。当然，这个模型并不是一种规范，只是用来理解Restful的工具。所以，做到了Level2，也就是面向资源和使用http动词，就已经很Restful了。

Level 1 解释了如何通过分治法(Divide and Conquer)来处理复杂问题，将一个大型的服务端点(Service Endpoint)分解成多个资源。
Level 2 引入了一套标准的动词，用来以相同的方式应对类似的场景，移除不要的变化。
Level 3 引入了可发现性(Discoverability)，它可以使协议拥有自我描述(Self-documenting)的能力。
这一模型帮助我们思考我们想要提供的HTTP服务是何种类型的，同时也勾勒出人们和它进行交互时的期望。

❶ REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计 RESTful API（REST风格的网络接口）；

❷ Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心，
URL定位资源，用HTTP动词（GET/POST/DELETE/PATCH）来描述操作，

❸ 用HTTP协议里的动词来实现资源的添加、修改、删除等操作。即通过HTTP动词来实现资源的状态转移：

❹ Server和Client之间传递某资源的一个表现形式，比如用JSON，XML传输文本，或者用JPG，WebP传输图片等。当然还可以压缩HTTP传输时的数据（on-wire data compression）;

❺ 用 HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误等。

好了，理解了RESTful的概念，究竟如何应用，这是个问题。根据项目的需求不同，我们的API设计规范也存在差别，完全看自身理解，满足自身需求，大的理念不变，根据需求制定项目的API规范就是好的RESTful。

Ⅸ php怎么开发rest api

“表面看来，良好的REST API很简单，即使后端很复杂，” Hazlewood在一次采访说到。一个 API 关注一系列的东西，以及如何表现个人的东西。减少API集合，搜索所有书籍和出版刊物，你会发现一个简洁的解决方案，它很直观，且不是太复杂。

Ⅹ Docker PHP 入门实践(三)

在本教程的其余部分，我们将基于 ThinkPHP 框架完成一个天气查询的应用。使用 天气查询-API文档-开发指南-Web服务 API | 高德地图API 的接口来实现我们的功能。把查询数据缓存到 MySql 中，这样就不用每次频繁的请求第三方的接口了（有请求次数限制）

选择高德开放平台-天气查询 API 主要是因为它是免费的。当然你也可以使用其他的第三方天气查询接口，看个人喜好。
该应用是一个非常简单的 REST API 应用，主要实现两个接口。

在我们进行应用编码之前，首先使用 Docker 安装并运行 ThinkPHP

ThinkPHP 是一个免费开源的，快速、简单的面向对象的 轻量级PHP开发框架 ，是为了敏捷WEB应用开发和简化企业应用开发而诞生的。ThinkPHP从诞生以来一直秉承简洁实用的设计原则，在保持出色的性能和至简代码的同时，更注重易用性。遵循 Apache2 开源许可协议发布，意味着你可以免费使用ThinkPHP，甚至允许把你基于ThinkPHP开发的应用开源或商业产品发布/销售 。

这就是为什么我选择它作为本教程的教学框架。我不想让你因为一个框架而放弃，但我也不想从头开始建立所有的东西，因为该教程的重点是Docker，而不是我们的PHP应用。

用Docker 创建 ThinkPHP 应用 实际上比用本地配置PHP环境所需的操作少。并且为我们还需要使用 Composer，多亏了Docker，我们甚至不需要在主机上安装它。

首先打开你的终端，创建一个项目目录。

并进入到该目录中

现在使用[官方Composer Docker镜像]（https://hub.docker.com/_/composer/）安装 ThinkPHP 。

如果你查看weather-app/目录，你会看到 ThinkPHP 6 的项目目录，如下所示：

我们的 docker 运行命令与第二章中的命令相似，但我们使用了不同的镜像。我们没有使用运行hello.php 脚本的 PHP 镜像，而是使用了一个 Composer 镜像。让我们来看看有什么变化。

项目创建完成后，我们需要添加几个路由 URL 和 Controller 文件 。让我们打开 weather-app 目录下的 app/controller , 然后新建 Weather.php 文件，内容如下：

然后打开 weather-app 目录下的 app/route , 在 app.php 文件中追加如下内容：

现在我们可以在 Docker 容器中运行我们的应用程序，只是为了验证我们的程序是否运行正常，因为我们只添加了两个路由 URL。打开命令行，运行。

现在，在浏览器中打开 http://localhost:38000/weather-app/public/index.php/weather/1，你应该看到一个空页面，上面有以下文字:

那么恭喜你，你刚刚已经成功地在 Docker 中运行了你的第一个 ThinkPHP 应用程序。

这次我们使用的docker run命令与我们用来运行 hello.php 脚本 和composer create-project ...的两个命令不同。原因是这次我们想获得包含 Apache 的最新版本的PHP，这样我们就可以为我们的 Web 应用提供服务。让我们更详细地了解新增的命令部分。

你可以通过向终端发送一个 "中断 "信号来停止和退出终端。在 windows 上，这可以通过按 Ctrl 和按c来实现。

运行你的新网络应用程序的另一个选择是在 "Detached"模式中运行容器。这意味着你在终端将不会看到来自你的容器的输出。这可以通过在我们之前的命令中添加-d标志来实现。

在分离模式下启动容器后，你的终端将显示新容器的完整ID--类似于a70d25c2a7cedae673f8ab...如果你想停止这个容器，你可以使用docker stop命令，用容器的ID告诉Docker。比如说

因为输入整个ID是很麻烦的，如果你愿意，Docker允许你只输入前三个或更多的字符。

最后，我建议为你的容器命名。我们在本书后面的许多例子中都会这样做，因为用名字来记住一个容器比用随机分配的ID要容易得多，再加上ID是随机的，所以每次你运行一个新版本的容器时，它都会得到一个新的ID。只要不是已经有一个同名的容器，名字就可以多次发出来。为了给我们的新应用容器命名，我们可以用传入的--name标志重新创建它。

在使用docker run命令时，还有许多可用的选项，所以你可能想更详细地阅读文档。在我们开发其余的应用程序时，我们会涉及其中的一些选项。

现在我们要引入高德的天气 SDK ，在使用该 SDK 之前你需要阅读高德开放平台-天气查询的技术文档，再添加 SDK 之前我们首先要确保所有现有的容器都停止了。

这个命令将列出所有正在运行的容器。你也可以通过添加-a标志来查看停止的容器。
如果有任何容器正在运行，那么在我们继续前进之前，使用docker stop 来停止它们。

该命令将在你的项目中装新的软件包。在这个过程中，你应该在终端看到一些类似这样的输出。

现在 SDK 已经安装完毕，可以使用了。

我们将使用刚刚添加的高德天气 SDK 来完善我们的业务逻辑，打开 controller 目录下的 Weather.php 添加以下内容：

我们做了一些更新--主要是对引入天气 API 初始化天气类

我们的应用程序已经初步完成了向API传递一个真实的位置ID并返回一些数据。首先，使用这个高德位置查询找到一个位置ID。我使用的是上海的ID进行测试。310000，当然你直接传 上海 也是可以的。ok，让我们再次运行Docker容器。

并在你的浏览器中访问正在运行的应用程序，地址是http://localhost:38000/weather-app/public/index.php/weather/310000。你应该可以看到一个JSON数据，看起来像这样。

你的 Docker 化的 PHP 应用程序现在正从外部数据源返回真实数据，并在Apache中提供服务，但你可能会注意到，它的速度并不快（我的页面加载时间为1.92秒！）。
高德天气 API 是一个免费的服务，其他国家可能无法访问。为了解决这个问题，我们将把查询的数据保存在我们自己的 MySQL 数据库中，可以再下次访问的时候可以快速地响应。这将极大地提高性能，下个章节我们将学习如何用 Docker 将 MySql 与 PHP 应用程序相结合。