Propósito de la API REST?

En primer lugar, entiendo que este es un complemento en el punto actual, pero sin duda es casi parte de WordPress de todos modos. Así que espero que esto no se marque como fuera de tema.

He leído sus documentos oficiales, muchos otros artículos y he visto videos tutoriales, pero todavía no entiendo algunos de los puntos. Este es ciertamente el futuro de WordPress, es muy útil para el desarrollo de aplicaciones móviles y para usar / compartir datos entre diferentes sitios pero: ¿qué hace solo para mi sitio?

Considera esto:

Actualmente estoy trabajando en los comentarios. Quiero que la sección de comentarios se cargue solo cuando el usuario se desplaza a la sección de comentarios (con un desplazamiento de -200px, para que no haya demora) .

• Voy a activar una llamada ajax cuando el usuario se desplace a ese punto
• La llamada Ajax envía algunos datos con ella, como post_id etc.
• Ejecutar WP_Comment_Query()en servidor
• Enviar JSONdatos al cliente con relaciones de comentarios, nombres, contenido, etc.
• Use JavaScript document.createElement(), innerHTML etc. para crear y generar comentarios

Ahora ... ¿Por qué usaría REST API en su lugar? ¿De qué me sirve? ¿Solo a prueba de futuro?

Todavía necesitaría usar JavaScript para generar todos los datos que obtengo. No encontré ningún buen artículo sobre por qué o para qué debería usar la API REST (excepto la transferencia de datos entre sitios y el desarrollo de aplicaciones móviles) .

En su estado actual, es una característica mal diseñada que no tiene ninguna ventaja real para un desarrollador competente.

La idea básica, tal como está en el momento en que se escribe esta respuesta, es exponer la funcionalidad central de WordPress como API JSON REST. Esto permitirá desacoplar la lógica "empresarial" de WordPress de la interfaz de usuario y crear diferentes interfaces de usuario completas o parciales para administrar y extraer información de WordPress. Esto por sí solo no es una revolución, sino una evolución. solo un reemplazo de la API XML-RPC que por sí sola optimiza el HTTP basado en la API de envío.

Al igual que con cualquier evolución, en cada paso puede preguntarse qué ventaja obtiene del estado anterior, y la respuesta es probablemente "no mucho", pero es de esperar que los pasos se acumulen en una gran diferencia.

Entonces, ¿por qué el prefacio negativo a esta respuesta? Porque mi experiencia como desarrollador de software es que rara vez es posible diseñar una API genérica que sea realmente útil sin tener que responder a casos de uso concretos. Un caso de uso concreto aquí puede ser reemplazar la API XML-RPC para la gestión automática de WordPress, pero cualquier front-end relacionado debe ser específico del sitio y, dado que existe una gran penalización de rendimiento por cada solicitud enviada desde el cliente al servidor, no puede simplemente uso agregado de diferentes API para obtener el resultado que desea de una manera en la que los usuarios seguirán contentos. Esto significa que para el front end, para un uso no trivial, todavía habrá muy poca diferencia en el esfuerzo de desarrollo entre el uso de la ruta AJAX y la ruta REST-API.

Las dos ventajas principales son:

1. Puede (eventualmente) hacer todas las tareas administrativas sin la interfaz de administración.
2. Puede obtener todos los datos para mostrar y eliminar el front-end (y escribir PHP) por completo.

En cuanto a su ejemplo específicamente

Reemplace los pasos 3 y 4 con la API REST, y reemplace los pasos 1, 2 y 5 con Backbone.js. BOOM, aplicación web dinámica. O tal vez se sienta más cómodo haciendo el enrutamiento complejo necesario para su sitio con Python.

Bueno, algunas cosas en realidad.

1. Le permite ejecutar funciones específicas según sea necesario, en lugar de requerir todo el cálculo de una carga de página completa. Por lo tanto, puede actualizar los comentarios periódicamente con una sobrecarga bastante baja sin necesidad de actualizar la página simplemente llamando a ese punto final de la API y actualizando los datos en su página. Este concepto eventualmente se extrapolará a los SPA (aplicaciones de una sola página) que cargan el sitio "cliente" rápidamente una vez, y emula todos los "cambios" de la página sin necesidad de volver a extraer el HTML de la página cada vez. Esto ya es muy popular con la llegada de frameworks como Angular, Ember y React. Los sitios pueden responder con una velocidad vertiginosa, mientras descargan algo de poder de cómputo al usuario final (ciclo de procesamiento, lógica no comercial) y reducen significativamente el número total de llamadas al servidor (solo extraiga los datos que necesita,

2. Separa la lógica empresarial y el renderizador. Sí, puede usar la API con otro sitio PHP escupiendo los resultados, o manejarlo con Javascript como lo mencionó, pero también puede consumirlo con una aplicación móvil nativa, una aplicación de escritorio, etc. No solo eso, sino que podría tener uno de cada uno hablando con la misma API, que realiza constantemente la misma lógica de negocios, lo que a su vez crea consistencia y confiabilidad entre los diversos clientes que consumen la API.

Las API son buenas porque separan las preocupaciones de la lógica y la visualización.

La API REST de WordPress es la nueva moda. Con aplicaciones de una sola página impulsadas por js, y WordPresses desea convertirse en una plataforma de aplicaciones, esto tiene mucho sentido. El plan es reemplazar XML-RPC con la API REST (¡lo cual es bueno solo por razones de seguridad!)

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

• El nuevo sitio del New York Times está construido sobre él, aparentemente .
• Permite que las aplicaciones móviles y otros servicios externos accedan al contenido de wp (como wp-cli )
• Permite a los desarrolladores crear un front-end de aplicaciones de una sola página con su marco de consumo JSON favorito de la semana, y tener todas las interacciones geniales a su alcance.
• Permite la separación de preocupaciones (como se mencionó anteriormente) y una mayor independencia entre los equipos de back-end y front-end.

Es otro conjunto de herramientas para llevar WordPress hacia adelante. Y, aunque ha sido un viaje sinuoso para llegar a donde estamos, creo que vale la pena tomarse el tiempo para explorarlo y comprenderlo.

Lo primero es lo primero: REST es liviano

En una línea: cuando usamos API REST, realizamos toda la representación de datos en el lado del cliente (bucles, condiciones y llamadas del lado del servidor, etc.) ahorrando ancho de banda y, al mismo tiempo, nuestra aplicación está lista para cualquier plataforma móvil, integraciones de terceros y modularizada ( separación de preocupación entre la interfaz y el lado del servidor).

¿No quieres esto?

Además de los 2 grandes puntos mencionados por @Milo, utilizo específicamente la API REST para exponer mis datos a aplicaciones que no son de WordPress. Tenemos una extensión de Chrome que extrae información de nuestra base de datos de WordPress, y esto se logra golpeando los puntos finales de la API REST con solicitudes POST.

Infraestructura CONSISTENTE

La API REST es consistente y legible por humanos. Es autodocumentado.

GET wp-json/wp/v2/postsEstá bastante claro lo que hace. EsoGET algunas publicaciones.

Tienes un espacio de nombres: wpuna versión:v2 y una colección de objetos.posts

¿Puedes adivinar qué GET wp-json/wp/v2/posts/5? Qué tal si :GET wp-json/wp/v2/posts/5/comments Qué tal:GET wp-json/shop/v2/orders/345/lines/11/price

Un desarrollador puede adivinar fácilmente al ver eso, obtendrá el precio de la línea 11en el pedido, 345incluso sin leer la documentación. El desarrollador incluso puede decir fácilmente que proviene del shopcomplemento ya que tiene un espacio de nombres.

¿ POST /wp-json/v2/posts title=New Blog Post Qué tal? ¿ Qué tal?PUT /wp-json/v2/posts title=New Title

Eso también está bastante claro. Hace una nueva publicación. Por cierto, devuelve la ID de la nueva publicación. No se trata de AJAX O la API REST. AJAX es simplemente una tecnología que accede a la API REST. Considerando que, antes, se tendría que llegar a un montón de nombres de función ajax abstractos como: get_price_for_lineitem( $order, $line ). ¿Eso devolverá solo un número o un objeto JSON? No estoy seguro, ¿dónde está la documentación? Oh ... fue la llamada ajax get_order_line_priceoget_lineitem_price .

El desarrollador no tiene que tomar estas decisiones, porque la wp-jsonAPI existente proporciona un buen modelo base a seguir al crear sus propios puntos finales. Claro, un desarrollador de plugins o api puede romper estas reglas, pero en general es más fácil seguir un estándar que ya se ha establecido y la mayoría de los desarrolladores preferiría seguir un patrón ya establecido (vea cuán generalizados son ahora los patrones de jQuery).

ABSTRACCIÓN sin distracción

¿Me importa cómo POST /wp-json/mysite/v1/widgets title=Foobarfunciona? No Solo quiero crear una nueva Widgety quiero la ID a cambio. Quiero hacerlo desde un formulario en mi front end sin actualizar la página. Si hago una solicitud a una URL, no me importa si es PHP, C #, ASP.NET o cualquier otra tecnología. Solo quiero crear un nuevo widget.

La API REST desacopla el backend desde el frente. Técnicamente, si su API es lo suficientemente buena, podría cambiar toda su pila de back-end. Siempre y cuando mantenga la misma estructura de API REST, cualquier cosa que dependiera de la API no se vería afectada.

Si su API REST es lo suficientemente simple y consistente, utilizando un nombre Widgetscomo una colección de objetos y un nombre / identificador como Widget/2para indicar una sola entidad, es realmente sencillo escribir esa API en una tecnología muy diferente, ya que es una tubería de base de datos más o menos básica código.

Utiliza verbos de solicitud HTTP estándar.

Las API REST aprovechan el núcleo de cómo funciona la web y los VERBs (léase: acción) que usa map to data CRUD de datos estándar.

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

Hay más verbos HTTP, pero esos son los conceptos básicos. Cada solicitud por Internet utiliza estos verbos. Una API REST se encuentra justo encima del modelo en el que la web está construida a pedido. No hay necesidad de ninguna capa de comunicación o modelo de abstracción intermedio. Es solo una solicitud http estándar a una URL y devuelve una respuesta. No puedes ser mucho más simple que eso.

Esencialmente, hace que un desarrollador sea más consciente de los aspectos básicos de cómo funciona realmente la web y cuando te acercas a comprender cómo funcionan los protocolos subyacentes, terminas haciendo un producto mejor y más eficiente.