REST API propósito?

15

En primer lugar, entiendo que este es un complemento en el punto actual, pero de todas formas es casi casi parte de WordPress. 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 de tutoriales, pero aún no consigo algunos de los puntos. Este es ciertamente el futuro de WordPress, es muy útil para el desarrollo de aplicaciones móviles y para usar / compartiendo 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 -200px offset, para que no haya demora) .

  • Voy a activar la llamada ajax cuando el usuario se desplace hasta ese punto
  • La llamada Ajax envía algunos datos con ella, como post_id etc
  • Ejecutar WP_Comment_Query() en el servidor
  • Envíe los datos de JSON 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 la API REST? ¿Cuál es el uso para mí? ¿Solo a prueba de futuro?

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

    
pregunta N00b 02.03.2016 - 18:50

7 respuestas

6

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 se encuentra en el momento en que se escribe esta respuesta, es exponer la funcionalidad central de WordPress como API REST de JSON. Esto permitirá el desacoplamiento de la lógica "comercial" de WordPress de la interfaz de usuario y permitirá crear diferentes interfaces de usuario completas o parciales para administrar y extraer información de wordpress. Esto por sí mismo no es una revolución, sino una evolución. solo un reemplazo de la API de XML-RPC que, de por sí, agiliza un poco la API basada en HTTP para el envío.

Como 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 de esta respuesta? Debido a que mi experiencia como desarrollador de software es que rara vez es posible diseñar una API genérica que sea realmente útil sin tener casos de uso concretos a los que responder. Un caso de uso concreto aquí puede ser reemplazar la API de XML-RPC para la gestión automatizada de wordpress, pero cualquier front-end tiene que ser específico del sitio y, dado que existe una gran penalización en el rendimiento por cada solicitud enviada desde el cliente al servidor, no puede el uso agregado de diferentes API para obtener el resultado que desea de una manera en la que los usuarios permanecerán felices. Esto significa que para el front-end, para uso no trivial, todavía habrá muy poca diferencia en el esfuerzo de desarrollo entre usar la ruta AJAX y la ruta REST-API.

    
respondido por el Mark Kaplun 03.03.2016 - 01:58
3

Las dos ventajas generales son:

  1. Puede (eventualmente) realizar todas las tareas de administración sin la interfaz de administración.
  2. Puede obtener todos los datos para mostrar y eliminar el extremo delantero (y escribir PHP) por completo.

Respecto a tu ejemplo específicamente-

Reemplaza los pasos 3 y amp; 4 con la API REST, y reemplace los pasos 1, 2 y 5 con Backbone.js. BOOM, aplicación web dinámica. O quizás esté más cómodo haciendo el enrutamiento complejo necesario para su sitio con Python en su lugar.

    
respondido por el Milo 02.03.2016 - 19:55
3

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 API y actualizando los datos en su página. Eventualmente, este concepto se extrapolará a las SPA (aplicaciones de una sola página) que cargan el sitio "cliente" una vez y emulan 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 el advenimiento de marcos como Angular, Ember y React. Los sitios pueden responder con una velocidad asombrosa, mientras que ambos descargan algo de potencia computacional para el 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, en lugar de volver a cargarlos) todo cada vez).

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

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

    
respondido por el Colt McCormack 02.03.2016 - 22:05
2

La API REST de WordPress es el nuevo hotness. Con aplicaciones impulsadas por js de una sola página, 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!)

enlace

  • El nuevo sitio de New York Times está construido en é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 una aplicación de una sola página front-end con sus El marco de trabajo de la semana favorito de JSON, y tiene todos los interacciones geniales a su alcance.
  • Permite la separación de inquietudes (como se mencionó anteriormente) y una mayor independencia entre los equipos de back-end y front-end.

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

    
respondido por el Jeremy Ross 02.09.2016 - 20:27
1

Lo primero es lo primero: REST es liviano

En una línea - Cuando utilizamos las API REST, hacemos todo el procesamiento 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 (separa la preocupación entre frontend y servidor).

¿No quieres esto?

    
respondido por el Divyanshu Jimmy 12.08.2017 - 07:31
0

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

    
respondido por el Nick F 02.03.2016 - 21:00
0

Infraestructura CONSISTENTE

La API REST es coherente y legible para el usuario. Es autodocumentada.

GET wp-json/wp/v2/posts es bastante claro lo que hace. Es GET s algunas publicaciones.

Tienes un espacio de nombres: wp , una versión: v2 y una colección de objetos posts

¿Puedes adivinar qué: GET wp-json/wp/v2/posts/5 hace? ¿Qué tal: 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 si observa eso, obtendrá el precio de la línea 11 en el pedido 345 incluso sin leer la documentación. El desarrollador puede incluso decir fácilmente que proviene del complemento shop , ya que tiene un espacio de nombre.

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

Eso también está bastante claro. Hace un nuevo post. Por cierto, devuelve el 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. Mientras que, antes, tendrías que encontrar un montón de nombres de funciones abstractas ajax como:  %código%. ¿Eso va a devolver solo un número, o un objeto JSON? No estoy seguro, ¿dónde está la documentación? Oh ... fue la llamada ajax get_price_for_lineitem( $order, $line ) o get_order_line_price .

El desarrollador no tiene que tomar estas decisiones, porque el get_lineitem_price api existente proporciona un buen modelo base para seguir al crear sus propios puntos finales. Claro, un desarrollador de plugin 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ían seguir un patrón ya establecido (ver cómo están ahora los patrones de jQuery generalizados).

ABSTRACCIÓN sin distracción

¿Me importa cómo funciona wp-json ? No Solo quiero crear un nuevo POST /wp-json/mysite/v1/widgets title=Foobar y quiero el ID a cambio. Quiero hacerlo desde un formulario en mi parte frontal 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 su pila de back-end completa. Mientras mantuvieras la misma estructura de API REST, no se vería afectado nada de lo que dependiera de la API.

Si su API REST es simple y lo suficientemente consistente, usar un sustantivo como Widget como una colección de objetos y un nombre / identificador como Widgets para indicar una sola entidad, es realmente sencillo escribir esa API en una forma muy diferente La tecnología es más o menos un código básico de fontanería de base de datos.

Utiliza verbos de solicitud HTTP estándar.

Las API REST aprovechan el núcleo de cómo funciona la web y los VERB (lectura: acción) que utiliza para asignar funciones de 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 individual a través de Internet utiliza estos verbos. Una API REST se encuentra justo encima del modelo en el que se basa la web a partir de solicitudes. No hay necesidad de ninguna capa de comunicación o modelo de abstracción en el medio. Es solo una solicitud http estándar a una URL y devuelve una respuesta. No puedes conseguir mucho más simple que eso.

Esencialmente, hace que un desarrollador esté más al tanto de las tuercas y los pernos de cómo funciona realmente la web y cuando te acercas más a la comprensión de cómo funcionan los protocolos subyacentes, terminas haciendo un producto mejor y más eficiente.

    
respondido por el Armstrongest 07.12.2017 - 02:37

Lea otras preguntas en las etiquetas