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.