Solución:
La idea de REpresentacional State Transfer no se trata de acceder a los datos de la forma más sencilla posible.
Sugirió usar solicitudes de publicación para acceder a JSON, que es una forma perfectamente válida de acceder / manipular datos.
REST es una metodología para significativo acceso de datos. Cuando vea una solicitud en REST, debería ver inmediatamente lo que está sucediendo con los datos.
Por ejemplo:
GET: /cars/make/chevrolet
es probable que devuelva una lista de autos Chevy. Una buena API REST incluso podría incorporar algunas opciones de salida en la cadena de consulta como ?output=json o ?output=html lo que permitiría al usuario decidir en qué formato debe codificarse la información.
Después de pensar un poco sobre cómo incorporar razonablemente la escritura de datos en una API REST, he llegado a la conclusión de que la mejor manera de especificar el tipo de datos explícitamente sería a través de la extensión de archivo ya existente, como .js, .json, .html, o .xml. Si falta una extensión de archivo, el formato predeterminado sería el predeterminado (como JSON); una extensión de archivo que no es compatible podría devolver un 501 Not Implemented código de estado.
Otro ejemplo:
POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }
es probable que cree un nuevo chevy malibu en la base de datos con los colores asociados. yo digo probable ya que la API REST no necesita estar directamente relacionada con la estructura de la base de datos. Es solo una interfaz de enmascaramiento para que los datos verdaderos estén protegidos (piénselo como accesores y mutadores para una estructura de base de datos).
Ahora tenemos que pasar al tema de la idempotencia. Por lo general, REST implementa CRUD sobre HTTP. Usos HTTP GET, PUT, POST y DELETE para las solicitudes.
Una implementación muy simplista de REST podría utilice el siguiente mapeo CRUD:
Create -> Post
Read -> Get
Update -> Put
Delete -> Delete
Hay un problema con esta implementación: Post se define como un método no idempotente. Esto significa que las llamadas posteriores del mismo método de publicación darán como resultado diferente estados del servidor. Obtener, Poner y Eliminar son idempotentes; lo que significa que llamarlos varias veces debería resultar en un estado de servidor idéntico.
Esto significa que una solicitud como:
Delete: /cars/oldest
en realidad podría implementarse como:
Post: /cars/oldest?action=delete
Mientras que
Delete: /cars/id/123456
resultará en el mismo estado del servidor si lo llama una vez, o si lo llama 1000 veces.
Una mejor manera de manejar la remoción del oldest artículo sería solicitar:
Get: /cars/oldest
y usa el ID de los datos resultantes para hacer un delete solicitud:
Delete: /cars/id/[oldest id]
Un problema con este método sería si otro /cars elemento fue agregado entre cuando /oldest fue solicitado y cuando el delete se emitió.
Ésta es una cuestión de seguridad y mantenibilidad.
métodos seguros
Siempre que sea posible, debe utilizar métodos “seguros” (unidireccionales) como GET y HEAD para limitar la vulnerabilidad potencial.
métodos idempotentes
Siempre que sea posible, debe utilizar métodos ‘idempotentes’ como GET, HEAD, PUT y DELETE, que no pueden tener efectos secundarios y, por lo tanto, son menos propensos a errores / más fáciles de controlar.
Fuente
En resumen, REST enfatiza los sustantivos sobre los verbos. A medida que su API se vuelve más compleja, agrega más cosas, en lugar de más comandos.