Considere un lenguaje donde todas las construcciones (como las funciones) son objetos. Entonces los verbos REST son simplemente llamadas convenciones y declaraciones de asignación. Para JavaScript, puede definir una sintaxis verbal fija como FACTURA para llamar a una función, BORRAR (lo mismo que eliminar en js) para eliminar un objeto en otro objeto, SET para asignar un valor y RETORNO para devolver un valor. Podríamos utilizar los verbos HTTP para indicar la función POST - invocar equivalente, PUT - asignar valor, GET - devolver un valor, - DELETE - eliminar un objeto. Estaba atrapado en la idea de que los métodos HTTP en realidad describían métodos de objetos, interfaces de objetos reales, que no podía ver que en realidad pudiera describir conceptos de niveles mucho más bajos, como las construcciones de lenguaje básicas que son claramente fijas y finitas en todos lenguas sanas Los verbos HTTP definen la sintaxis de manipulación de objetos y la estructura de objetos de nivel superior define los métodos API.

Y, por supuesto, es útil para que el enrutamiento / proxy tenga un vocabulario fijo para reflexionar.

La terminología de "verbo" y "sustantivo" es algo desafortunada aquí. Como ya mencionó, puede crear fácilmente un objeto por función. Todos los lenguajes orientados a objetos, excepto Java, tienen esa transformación incorporada y en Java terminas haciéndolo todo el tiempo de todos modos, terminando con muchos objetos con un solo método y, a menudo, uno llamado "invocar", "ejecutar", "aplicar" o algo así (por lo que son los lenguajes de programación donde la distinción "verbo" / "nombre" en realidad no tiene sentido).

Los "verbos" de REST se asemejan más a la clasificación de sus métodos a los captadores, definidores (eliminadores, pueden considerarse como configuradores) y otros. Y tratando de hacer todo con captadores y setters. La razón de esto es:

1. Semántica más sencilla ante el fallo de la comunicación, ya que tanto los captadores como los configuradores son idempotentes. Obtener el recurso dos veces no tiene ningún efecto adicional y tampoco lo establece al valor que ya tiene.
2. Definir algunas semánticas que se pueden usar posiblemente almacenando un proxy que no entiende la interfaz específica. Los recolectores se almacenan en caché y se sabe que los configuradores invalidan el caché.

HTTP se diseñó desde el principio teniendo en cuenta tanto las memorias caché como la tolerancia a fallos, por lo que estos dos puntos conducen a sus cuatro métodos básicos:

• GET es un captador. Se asume que no modifica el estado del servidor y devuelve el mismo valor cada vez con la posibilidad de especificar la política de caducidad y revalidación.
• PUT y DELETE son el definidor y el eliminador (= setter con nil). Normalmente no se utilizan en el contexto de la web normal, pero tienen sentido para REST.
• POST es un fregadero de cocina genérico de "invocación" para el cual los cachés no pueden asumir nada.

REST es un patrón de diseño que describe cómo usar HTTP en bruto o protocolos de red similares para implementar la interfaz que permite un fácil manejo de fallas al reintentar y funciona bien con servidores proxy de almacenamiento en caché.

No se corresponde fácilmente con la API regular de programación orientada a objetos. Creo que en realidad es algo bueno. Los desafíos de la interfaz a través de la red, que es intrínsecamente no confiable y donde los viajes de ida y vuelta son mucho más lentos que transferir una cantidad de llamada de datos incluso moderada para un enfoque de diseño diferente al de la API en proceso, de modo que cuando parece diferente, las personas no intentan aplicar La experiencia del otro dominio no es válida (esa es la ruina de SOAP, XML-RPC y demás; parece ser una llamada a un procedimiento, pero no funciona así y termina siendo un dolor trabajar).

La idea esencial es que la complejidad se expresa a través de la representación del recurso, por lo que no se necesitan verbos adicionales. Como algunos lo han dicho: "En REST, los sustantivos son buenos, los verbos son malos".

Si observa los cuatro verbos REST, se pueden asignar a las operaciones CRUD básicas, lo que esencialmente le permite hacer lo que quiera con sus recursos. Eso es -

  

POST - Crea el recurso

     

GET - Lee el recurso

     

PUT - Actualizar el recurso

     

ELIMINAR - Eliminar el recurso

¿Qué más necesitas?

• Porque un programador profesional anticipa cientos, sino miles de nombres de métodos de lo contrario. Lo que parece inútil en un pequeño más pequeño puede ser muy importante a medida que la aplicación se hace más grande.

• Porque no hay necesidad de estándares sobre nombres de métodos cuando ya están definidos.

• Porque el objetivo principal del código se puede leer sin tales traducciones adicionales.

• Porque fomenta y ayuda en la identificación de 'cuándo' se debe separar otra clase.

• Cuando tomas el código, es razonable y en realidad es posible entender qué y cómo lo hace mucho más rápido.

• Proporciona un vocabulario común y, por lo tanto, un nivel de abstracción para que pueda centrarse en otros detalles y ver patrones.

• Facilita la búsqueda de errores, ya que el código y los enfoques comunes se pueden verificar fácilmente.

• Cuando trabajas con múltiples 'capas' como una en el desarrollo web, saber qué URL coincide con qué nombre de acción es muy útil para la depuración.

En general, no 'siempre' lo necesitas, pero como la mayoría de los estándares, ¡tiene mucho sentido tratar de usarlo!

La alternativa es algo horrible: WSDL (también conocido como lenguaje de definición de servicios web), que es una manera (torpe) de describir mediante programación (de alguna manera) APIS arbitraria.

REST limita gravemente los verbos, empujando casi todas las variaciones específicas de la aplicación a la carga útil del documento. La ventaja de hacerlo es que muchas implementaciones de clientes pueden comunicarse con muchos servicios heterogéneos. Los clientes y los servidores pueden ser completamente desconocidos entre sí, algunos aún no se han escrito.

Hay un podcast en el que Stefan Tilkov explica REST muy bien .

Sí, una API de descanso tiene un conjunto fijo de verbos, pero no tiene que limitarse a (o incluir GET, POST, PUT, DELETE). Me gustaría ver GET, POST, PUT, DELETE como una implementación predeterminada de REST que funciona para el 80% de todos los sistemas que existen.

Otros sistemas que están implementando más que operaciones crudas pueden (y lo hacen) implementar sus propios verbos para sus API REST. Verbos como Publicar, Consumir, Calificar, Comentar, Buscar, Examinar se pueden agregar e implementar en un sistema REST. Si bien algunos podrían decir que un vocabulario más amplio podría hacerlo más complicado, mi respuesta es que depende. Si su usuario objetivo son expertos en tecnología que entienden lo que es un POST, entonces sí, podría ser más complicado; sin embargo, si los usuarios de la API son personas reales (es decir, personas que no codifican y no saben qué es un POST), los verbos reales son mucho más fáciles de usar. De hecho, tener un conjunto adecuado de verbos para su API ayuda a mantener las URL cortas (lo cual es importante si desea que los usuarios las escriban en un navegador. Si usa un vocabulario personalizado, querrá asegurarse de que su API y sus verbos están bien documentados. Cuando utilice una API REST personalizada, querrá asegurarse de que sus "acciones de solo lectura" sean un GET HTTP y "acciones de escritura" con POST.

La red social para adolescentes, Piczo.com, (puede descansar en paz) presentó una API REST extendida (incluidos los verbos mencionados anteriormente) que se implementó en 7 idiomas diferentes.

Simple es bueno.

Hay casos en los que necesita verbos y complejidad adicionales, pero la mayoría de los problemas se pueden reducir a simples acciones CRUD en los recursos, y eso es lo que REST intenta promover. Cuando piensa en la mayoría de las aplicaciones web, al final, leen y conservan los registros en un almacén de datos, que utilizan las mismas acciones muy simples.

object.foo () está bien, pero ¿qué hace? ¿Qué está volviendo? ¿Está modificando el estado del objeto o alguna de sus dependencias? ¿Puedes llamarlo dos veces y obtener el mismo resultado o te dará dos valores diferentes? Si también tiene object.bar (), ¿deben llamarse en un orden específico?

Se requiere mucho conocimiento al usar una API enriquecida, y usualmente tienen sus propias convenciones (es decir, setFoo va a mutar el objeto, getBar es probablemente idempotente, dispose () o destroy () significa que no hay otras llamadas en el mismo objeto será posible, etc ...)