REST API的目的？

首先，我知道这是当前的插件，但是无论如何它几乎肯定是WordPress的一部分。因此，我希望这不会被标记为题外话。

我已经阅读了他们的官方文档，许多其他文章并观看了教程视频，但是我仍然没有得到一些要点。这当然是WordPress的未来，对于移动应用程序的开发以及在之间使用/共享数据非常方便。不同的网站，但是：它仅对我的网站有什么作用？

考虑一下：

我目前正在评论中。我希望注释部分仅在用户滚动到注释部分时才加载（具有-200px的偏移量，因此没有延迟）。

• 我将在用户滚动到该点时触发ajax调用
• Ajax调用发送一些数据吧，像post_id 等
• WP_Comment_Query()在服务器上运行
• JSON通过评论关系，名称，内容等将数据发送回客户端
• 使用JavaScript document.createElement()，innerHTML 等创建和输出评论

现在.. 为什么要改用REST API？对我有什么用？只是为了未来？

我仍然需要使用JavaScript来输出我得到的所有数据。.我找不到任何好的文章为什么或为什么我应该使用REST API （网站和移动应用程序开发之间的数据传输除外）。

在目前的状态下，它是一项设计不良的功能，对于有能力的开发人员没有任何真正的优势。

在编写此答案时，其基本思想是将WordPress核心功能公开为JSON REST API。这将使WordPress的“业务”逻辑与UI脱钩，并允许创建不同的完整或部分UI来管理和提取Wordpress中的信息。这本身不是一场革命，而是一场演变。只是XML-RPC API的替代，它本身可以简化基于HTTP的提交API。

与任何演变一样，您可能会问自己，从前一个状态中获得的好处是什么，而答案可能是“不多”，但希望这些步骤可以累积很大的不同。

那么，为什么对这个答案是否定的前言呢？因为我作为软件开发人员的经验是，在没有具体用例回答的情况下，几乎不可能设计出实际上有用的通用API。这里的一个具体用例可以代替XML-RPC API来进行自动wordpress管理，但是任何与前端相关的操作都必须针对特定地点，并且由于从客户端发送到服务器的每个请求都会受到巨大的性能损失，因此，聚合使用不同的API，以使用户保持满意的方式获得所需的结果。这意味着对于前端，对于非琐碎的用途，使用AJAX路由和REST-API路由之间的开发工作仍然几乎没有区别。

两个主要优点是：

1. 您可以（最终）在没有管理界面的情况下执行所有管理任务。
2. 您可以获取所有要显示的数据，并完全消除前端（并编写PHP）。

关于您的示例-

将步骤3和4替换为REST API，并将步骤1、2和5替换为Backbone.js。BOOM，动态Web应用程序。或者，也许您更愿意使用Python来完成网站所需的复杂路由。

好吧，实际上有几件事。

1. 它使您可以根据需要运行特定功能，而不需要整个页面加载的所有计算。因此，您可以以相当低的开销定期更新注释，而无需刷新页面，只需调用该API端点并更新页面上的数据即可。该概念最终将被推广到SPA（单页应用程序）中，这些SPA可以快速加载“客户端”站点一次，并模拟所有页面“更改”，而无需每次都重新拉动页面的HTML。随着Angular，Ember和React等框架的出现，这已经非常流行。站点可能会以惊人的速度做出响应，同时将一些计算能力转移给最终用户（渲染周期，非业务逻辑），并大大减少了对服务器的呼叫总数（仅提取所需的数据，

2. 它将业务逻辑和渲染器分开。是的，您可以将API与另一个PHP网站一起使用以吐出结果，或者像您提到的那样使用Javascript来处理它，但是您也可以将其与本机移动应用程序，桌面应用程序等一起使用。不仅如此，而且您可以每个人都与同一个API对话，该API始终执行相同的业务逻辑，从而在使用该API的各个客户端之间创建了一致性和可靠性。

API很好，因为它们将逻辑和显示的关注点分开了。

WordPress REST API是新的热点。对于单页js驱动的应用程序，WordPress希望成为一个应用程序平台，这是很有意义的。该计划是用REST API替换XML-RPC（仅出于安全原因，这是一件好事！）

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

• 显然，《纽约时报》的新网站就建立在该网站上。
• 它允许移动应用程序和其他外部服务访问wp内容（例如wp-cli）
• 它使开发人员可以使用他们本周最喜欢的JSON消耗框架来构建单页应用程序前端，并使所有有趣的交互都触手可及。
• 它允许将关注点分离（如上所述），并在后端和前端团队之间实现更大的独立性。

这是使WordPress向前发展的另一套工具。而且，尽管这是到达我们现在的曲折旅程，但我认为值得花时间去探索和理解它。

首先，REST是轻量级的

一行-当我们使用REST API时，我们在客户端进行所有数据渲染（循环，条件和服务器端调用等），从而节省了带宽，同时我们的应用程序可用于任何移动平台，第三者集成和模块化（前端和服务器端之间的关注点分离）。

你不想要这个吗？

除了提到的@Milo的2个要点之外，我还专门使用REST API将数据公开给非WordPress应用程序。我们有一个Chrome扩展程序，可从WordPress数据库中提取信息，这可以通过使用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，然后返回ID。我想从前端的表单中完成此操作，而无需刷新页面。如果我向URL发出请求，则不管它是PHP，C＃，ASP.NET还是任何其他技术。我只想创建一个新的小部件。

REST API将后端与前端解耦。从技术上讲，如果您的API足够好，则可以更改整个后端堆栈。只要您维护相同的REST API结构，任何依赖于API的内容都不会受到影响。

如果您的REST API简单且足够一致，则使用一个名词（如Widgets对象的集合）和名词/标识符（如Widget/2指示单个实体），以一种与众不同的技术来编写该API或多或少是基本的数据库工作，这真的很简单码。

使用标准HTTP请求动词。

REST API充分利用了网络工作原理的核心，以及您使用的VERB（映射为action）映射到标准数据CRUD函数。

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

HTTP动词更多，但这是基础。互联网上的每个请求都使用这些动词。REST API位于基于请求构建Web的模型的顶部。两者之间不需要任何通信层或抽象模型。这只是对URL的标准http请求，它返回响应。您不能比这更简单。

从本质上讲，它使开发人员更清楚地了解网络的实际工作原理，并且当您进一步了解底层协议的工作原理时，最终会生产出更高效，更好的产品。