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 應用程序相結合。