發現 · WordPress開發手冊

當您的客戶與未知網站交談時，您需要了解該網站的能力以及該網站的配置方式。這有幾個步驟，這取決于你需要發現什么。 ##發現API 連接到網站的第一步是找出網站是否啟用了API。通常，您將使用用戶輸入的URL，因此您訪問的網站可能是任何東西。發現步驟允許您驗證API是否可用，以及如何訪問它。 ##鏈接頭處理發現的首選方法是向所提供的地址發送HEAD請求。 REST API會自動將Link標頭添加到所有前端頁面，如下所示：鏈接：<http://example.com/wp-json/>; rel =“https://api.w.org/”> 該URL指向API的根路徑（/），然后將其用于進一步的發現步驟。對于沒有啟用“漂亮的永久鏈接”的網站，/ wp-json /不會被WordPress自動處理。這意味著將使用正常/默認的WordPress固定鏈接。這些標題看起來更像這樣：鏈接：<http://example.com/?rest_route=/>; rel =“https://api.w.org/” 客戶應牢記這種變化，并確保兩條路線能夠無縫地處理。此自動發現可以應用于WordPress安裝服務的任何URL，因此不需要添加用戶輸入的預處理。由于這是HEAD請求，所以請求應該安全地盲目發送到服務器，而不用擔心會產生副作用。 ##元素對于具有HTML解析器或在瀏覽器中運行的客戶端，通過“<link>”元素，前端頁面的<head>中包含了Link標題的等價物： ``` <link rel='https://api.w.org/' href='http://example.com/wp-json/' /> ``` In-browser Javascript can access this via the DOM: ``` // jQuery method var $link = jQuery( 'link[rel="https://api.w.org/"]' ); var api_root = $link.attr( 'href' ); // Native method var links = document.getElementsByTagName( 'link' ); var link = Array.prototype.filter.call( links, function ( item ) { return ( item.rel === 'https://api.w.org/' ); } ); var api_root = link[0].href; ``` 對于瀏覽器中的客戶端，或客戶端無法訪問HTTP標頭，這可能是更有用的發現API的方式。這與Atom / RSS feed發現類似，因此也可以自動為此目的使用現有的代碼改為代替。 ## RSD（真正簡單發現）對于支持XML-RPC發現的客戶端，RSD方法可能更適用。這是一種通常用于XML-RPC的基于XML的發現格式。 RSD有兩個步驟。第一步是找到RSD端點，以“<link>”元素的形式提供： ``` <link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://example.com/xmlrpc.php?rsd" /> ``` 第二步是獲取RSD文檔并解析可用的端點。這涉及在如下文檔中使用XML解析器： ``` <?xml version="1.0" encoding="utf-8"?> <rsd version="1.0" xmlns="http://archipelago.phrasewise.com/rsd"> <service> <engineName>WordPress</engineName> <engineLink>https://wordpress.org/</engineLink> <homePageLink>http://example.com/</homePageLink> <apis> <api name="WordPress" blogID="1" preferred="true" apiLink="http://example.com/xmlrpc.php" />  <api name="WP-API" blogID="1" preferred="false" apiLink="http://example.com/wp-json/" /> </apis> </service> </rsd> ``` REST API始終具有名稱屬性，其值等于WP-API。 RSD是自動發現的最不喜歡的方法，有幾個原因。基于RSD的發現的第一步涉及解析HTML以首先找到RSD文檔本身，這相當于<link>元素自動發現。然后，它需要另一個步驟來解析RSD文檔，這需要一個完整的XML解析器。在可能的情況下，由于復雜性，我們建議避免基于RSD的發現，但如果現有的XML-RPC客戶端已經啟用了RSD解析器，則可能更喜歡使用此方法。對于希望使用REST API作為逐步增強代碼庫的XML-RPC客戶機，這避免了需要支持不同形式的發現。 ##認證發現發現也可用于通過API可用的身份驗證方法。 API根的響應是描述API的對象，其中包含一個驗證密鑰： ``` { "name": "Example WordPress Site", "description": "YOLO", "routes": { ... }, "authentication": { "oauth1": { "request": "http://example.com/oauth/request", "authorize": "http://example.com/oauth/authorize", "access": "http://example.com/oauth/access", "version": "0.1" } } } ``` 認證值是認證方法ID與認證選項的映射（關聯數組）。這里提供的選項特定于身份驗證方法本身。有關特定身份驗證方法的選項，請參閱身份驗證文檔。 ##擴展發現一旦您發現了API，下一步就是檢查API支持的內容。 API的索引公開了命名空間項，其中包含支持的API的擴展名。對于使用版本4.4到4.6的WordPress網站，只有基本API基礎架構可用，而不是具有端點的完整API。這也包括oEmbed端點： ``` { "name": "Example WordPress Site", "namespaces": [ "oembed/1.0/" ] } ``` 具有完整API（即安裝了WordPress 4.7+或安裝了REST API插件）的網站也將在命名空間中使用wp / v2項目： ``` { "name": "Example WordPress Site", "namespaces": [ "wp/v2", "oembed/1.0/" ] } ``` 在嘗試使用任何核心端點之前，您應該確保通過檢查wp / v2支持來檢查API是否受支持。 WordPress 4.4啟用所有站點的API基礎架構，但不包括wp / v2下的核心端點。核心終端在WordPress 4.7中添加。這種相同的機制可用于檢測支持REST API的任何插件的支持。例如，拿一個注冊以下路由的插件： ``` <?php register_rest_route( 'testplugin/v1', '/testroute', array( /* ... */ ) ); ``` This would add the testplugin/v1 namespace to the index: ``` { "name": "Example WordPress Site", "namespaces": [ "wp/v2", "oembed/1.0/", "testplugin/v1" ] } ```