La idea de RE presentational S tate T ransfer no se trata de acceder a los datos de la manera más simple 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 el acceso significativo de datos. Cuando vea una solicitud en REST, debería aparecer 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 podría incluso incorporar algunas opciones de salida en la cadena de consulta como ?output=jsono ?output=htmllo que permitiría al accesor decidir en qué formato debe codificarse la información.
Después de un poco de pensar acerca de cómo la escritura de datos razonablemente integrarse en una API REST, he concluido que la mejor manera de especificar el tipo de datos de forma explícita sería a través de la extensión del archivo ya existente, como .js, .json, .html, o .xml. Una extensión de archivo faltante tendría el formato predeterminado predeterminado (como JSON); una extensión de archivo que no sea compatible podría devolver un 501 Not Implementedcó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. Digo probablemente 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 (piense en ellos como accesores y mutadores para una estructura de base de datos).
Ahora necesitamos pasar al tema de la idempotencia . Por lo general, REST implementa CRUD sobre HTTP. HTTP utiliza GET, PUT, POSTy DELETEpara las solicitudes.
Una implementación muy simple de REST podría usar el siguiente mapeo CRUD:
Create -> Post
Read -> Get
Update -> Put
Delete -> Delete
Hay un problema con esta implementación: la publicación se define como un método no idempotente. Esto significa que las llamadas posteriores del mismo método Post darán como resultado diferentes estados del servidor. Get, Put y Delete son idempotentes; lo que significa que llamarlos varias veces debería dar como resultado 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
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 eliminación del oldestartículo sería solicitar:
Get: /cars/oldest
y use los IDdatos resultantes para hacer una deletesolicitud:
Delete: /cars/id/[oldest id]
Un problema con este método sería si /carsse agregara otro elemento entre cuando /oldestse solicitó y cuándo deletese emitió.