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.