REST APIの目的は？

まず第一に、これは現時点ではプラグインであることを理解していますが、とにかくWordPressのほとんどの部分であると確信しています。したがって、これがトピック外としてフラグ付けされないことを願っています。

私は彼らの公式ドキュメント、他の多くの記事を読み、チュートリアルビデオを見ましたが、まだいくつかのポイントを得ていません。これは確かにWordPressの未来です。別のサイトがありますが、それは自分のサイトに対してのみ何をしますか

このことを考慮：

私は現在コメントに取り組んでいます。ユーザーがコメントセクションにスクロールしたときにのみコメントセクションをロードしたい（-200pxオフセットで、遅延がないように）。

• ユーザーがそのポイントまでスクロールするとajax呼び出しがトリガーされます
• Ajax呼び出しは、etcなどのデータを送信しますpost_id
• 実行WP_Comment_Query()サーバーに
• 送信JSONデータは、コメント関係、名前、コンテンツをクライアントにバックアップなど
• JavaScriptを使用document.createElement()、innerHTML などのコメントを作成して出力するには

今.. 代わりにREST APIを使用するのはなぜですか？私の用途は何ですか？ただ将来の保証？

取得したすべてのデータを出力するためにJavaScriptを使用する必要があります。RESTAPIを使用する理由と目的（サイトとモバイルアプリ開発の間のデータ転送を除く）についての良い記事が見つかりませんでした。

現在の状態では、それは有能な開発者にとって実際の利点を持たないひどく設計された機能です。

この答えが書かれた時点での基本的な考え方は、WordPressのコア機能をJSON REST APIとして公開することです。これにより、WordPressの「ビジネス」ロジックをUIから分離し、WordPressから情報を管理および抽出するためのさまざまな完全または部分的なUIを作成できます。これ自体は革命ではなく、進化です。XML-RPC APIの単なる置換であり、それ自体が送信APIに基づくHTTPを合理化します。

あらゆる進化と同様に、各ステップで、以前の状態からどのような利点が得られるかを自問するかもしれません。答えはおそらく「それほどではない」でしょうが、うまくいけば大きな違いにステップが蓄積されることを願っています。

では、なぜこの答えに対する否定的な序文なのでしょうか？ソフトウェア開発者としての私の経験では、具体的なユースケースに答えなくても実際に役立つ汎用APIを設計することはほとんど不可能だからです。ここでの具体的なユースケースは、自動化されたワードプレス管理のためにXML-RPC APIを置き換えることです。ただし、関連するフロントエンドはサイト固有である必要があります。さまざまなAPIを集約して使用し、ユーザーが満足する方法で必要な結果を得ます。これは、フロントエンドの場合、些細な使用法ではなく、AJAXルートとREST-APIルートを使用する場合の開発作業にほとんど違いがないことを意味します。

2つの包括的な利点は次のとおりです。

1. （最終的に）管理インターフェイスなしですべての管理タスクを実行できます。
2. すべてのデータを表示用に取得し、フロントエンド（およびPHPの記述）を完全に排除できます。

あなたの例について特に

手順3および4をREST APIに置き換え、手順1、2、および5をBackbone.jsに置き換えます。BOOM、動的Webアプリケーション。または、代わりにPythonを使用して、サイトに必要な複雑なルーティングを行う方がより快適かもしれません。

まあ、実際にはいくつかのことがあります。

1. ページ全体のロードのすべての計算を要求するのではなく、必要に応じて特定の機能を実行できます。そのため、APIエンドポイントを呼び出してページ上のデータを更新するだけで、ページを更新する必要なく、かなり低いオーバーヘッドで定期的にコメントを更新できます。この概念は、最終的に「クライアント」サイトをすばやく1回ロードするSPA（単一ページアプリケーション）に外挿され、ページのHTMLを毎回再プルする必要なくすべてのページ「変更」をエミュレートします。これは、Angular、Ember、Reactなどのフレームワークの出現ですでに非常に人気があります。サイトは驚異的な速度で応答する一方で、エンドユーザーにある程度の計算能力をオフロードし（レンダリングサイクル、非ビジネスロジック）、サーバーへの呼び出しの総数を大幅に削減します（必要なデータのみをプルし、

2. ビジネスロジックとレンダラーを分離します。はい、別のPHPサイトでAPIを使用して結果を出力したり、前述のようにJavascriptで処理したりできますが、ネイティブモバイルアプリケーション、デスクトップアプリケーションなどで使用することもできます。それだけでなく、それぞれが同じAPIと通信し、同じビジネスロジックを一貫して実行します。これにより、APIを使用するさまざまなクライアントで一貫性と信頼性が得られます。

APIは、ロジックと表示の懸念を分離するため、優れています。

WordPress REST APIは新しいホットネスです。単一ページのjs駆動型アプリケーションと、WordPressがアプリプラットフォームになることを望む場合、これは非常に理にかなっています。XML-RPCをREST APIに置き換える計画です（これはセキュリティ上の理由だけで良いことです！）

https://make.wordpress.org/core/2015/09/21/wp-rest-api-merge-proposal/

• ニューヨーク時間の新しいサイトは、その上に構築されて明らかに。
• モバイルアプリやその他の外部サービスがwpコンテンツ（wp-cliなど）にアクセスできるようにします
• 開発者は、お気に入りのJSONを使用する今週のフレームワークを使用して、単一ページのアプリフロントエンドを構築し、すべてのクールな対話をすぐに利用できます。
• （上記のように）懸念事項を分離し、バックエンドチームとフロントエンドチームをより独立させることができます。

WordPressを前進させるもう1つのツールセットです。そして、私たちがいる場所に行くのは曲がりくねった旅でしたが、時間をかけてそれを探索し理解する価値があると思います。

まず最初に-RESTは軽量です

1行-REST APIを使用する場合、クライアント側（ループ、条件、サーバー側の呼び出しなど）ですべてのデータレンダリングを行い、帯域幅を節約すると同時に、アプリケーションをモバイルプラットフォーム、サードパーティの統合、モジュール化の準備が整います（フロントエンドとサーバー側の懸念の分離）。

これが欲しくない？

@Miloが言及した2つの優れた点に加えて、特にREST APIを使用して、WordPress以外のアプリケーションにデータを公開します。WordPressデータベースから情報を引き出すChrome拡張機能があり、これはPOSTリクエストでREST APIエンドポイントをヒットすることで実現されます。

一貫したインフラストラクチャ

REST APIは一貫性があり、人間が読むことができます。それは自己文書化です。

GET wp-json/wp/v2/postsそれが何をするかはかなり明確です。これは、GETいくつかの記事をよ。

名前空間：wp、バージョン：v2およびオブジェクトコレクションがありますposts

あなたは何を推測できますかGET wp-json/wp/v2/posts/5？方法：GET wp-json/wp/v2/posts/5/comments 方法：GET wp-json/shop/v2/orders/345/lines/11/price

開発者はそれを見ることで簡単に推測でき、ドキュメントを読まなくても11注文のラインの価格を取得でき345ます。開発者shopは、名前空間があるため、プラグインからのものであることを簡単に知ることができます。

どうPOST /wp-json/v2/posts title=New Blog Post ですかPUT /wp-json/v2/posts title=New Title

それも非常に明確です。新しい投稿を作成します。ところで、新しい投稿のIDを返します。AJAXやREST APIについてのものではありません。AJAXは、単にREST APIにアクセスするテクノロジーです。一方、以前は、次のような一連の抽象AJAX関数名を考え出す必要がありました get_price_for_lineitem( $order, $line )。それは単に数値を返すのでしょうか、それともJSONオブジェクトを返すのでしょうか？ドキュメントはどこにあるのかわかりません。ああ... ajax呼び出しget_order_line_priceまたはget_lineitem_priceでした。

既存のwp-jsonAPIは、独自のエンドポイントを作成する際に従うべき基本モデルを提供するため、開発者はこれらの決定を行う必要はありません。確かに、プラグインまたはAPI開発者はこれらのルールを破ることができますが、一般に、既に設定されている標準に従うことは簡単であり、ほとんどの開発者は既に設定されているパターンに従うほうがはるかに優れています（jQueryパターンの普及状況をご覧ください）。

気を散らすことのない抽象

どのようにPOST /wp-json/mysite/v1/widgets title=Foobar機能するか気にしますか？いや。新しいものを作成したいだけでWidget、IDを返したいです。ページを更新せずに、フロントエンドのフォームから実行したいです。URLにリクエストを行う場合、それがPHP、C＃、ASP.NET、またはその他のテクノロジーのいずれであるかは気にしません。新しいウィジェットを作成したいだけです。

REST APIは、バックエンドをフロントから切り離します。技術的には、APIが十分であれば、バックエンドスタック全体を変更できます。同じREST API構造を維持している限り、APIに依存するものは影響を受けません。

Widgetsオブジェクトのコレクションのような名詞とWidget/2単一のエンティティを示すような名詞/識別子を使用して、REST APIが十分にシンプルで一貫している場合、多かれ少なかれ基本的なデータベースの配管であるため、非常に異なるテクノロジーでそのAPIを書くことは本当に簡単ですコード。

標準HTTPリクエスト動詞を使用します。

REST APIは、Webがどのように機能するかというコアと、標準データCRUD関数にマップするVERB（read：action）を利用します。

CREATE : POST
READ   : GET
UPDATE : PUT/PATCH
DELETE : DELETE

HTTP動詞は他にもありますが、それらは基本です。インターネット上のすべてのリクエストはこれらの動詞を使用します。REST APIは、リクエストに基づいてWebが構築されるモデルの上に配置されます。間に通信レイヤーや抽象化モデルは必要ありません。これはURLへの標準のhttp要求であり、応答を返します。あなたはそれよりはるかに簡単になることはできません。

基本的に、開発者はWebが実際にどのように機能するかをよりよく認識し、基礎となるプロトコルがどのように機能するかを理解するようになると、より効率的で優れた製品を作成します。