La mejor manera de entenderlo es leer la disertación de Roy T. Fielding en él, o artículos relevantes en su blog donde discute las diferencias entre REST puro y simplemente arquitecturas RPC.
Otra cosa a tener en cuenta es que el artículo de Wikipedia sobre REST está en pésima condición y el propio Fielding, el "inventor" de REST, sugiere que el artículo es inexacto.
Lo más importante que las personas extrañan con REST es la capacidad de descubrimiento: los recursos deben incluir URI para otros recursos relacionados dentro de su hipertexto, en lugar de basarse en las convenciones de nomenclatura de URI, que están fuera de banda y no estandarizadas.
Un gran problema con las implementaciones populares de RPC como SOAP o XML-RPC es que usan HTTP debajo de su propia arquitectura propietaria, en lugar de aprovechar todas las diferentes propiedades de HTTP como PUT, GET, DELETE, etc. También se ajusta a la pila web tradicional: un servidor de caché en el medio no funciona, por ejemplo, sin conocer el significado de los contenidos de la llamada RPC.
Esta es una introducción incompleta a REST y RPC pero creo que he resaltado algunos de los puntos importantes que a menudo se pasan por alto. Tenga cuidado, ya que hay MUCHA información incorrecta en REST.
Dicho esto, REST no es para todo. Es una arquitectura, por lo que es bastante flexible cómo puede implementarlo. Pero si no tiene sentido acceder a las cosas principalmente como recursos, entonces REST puede no ajustarse, o puede que solo se ajuste a partes de su aplicación, lo cual está bien.
no puede entender por qué se stackoverflow masivamente cerrando control de calidad del que han tenido gran impacto. – minghua