php - tutorial - API REST: ¿por qué usar PUT DELETE POST GET?

rest api tutorial español (8)

Entonces, estaba viendo algunos artículos sobre cómo crear API REST. Y algunos de ellos sugieren usar todos los tipos de solicitudes HTTP: como PUT DELETE POST GET . Creamos por ejemplo index.php y escribimos API de esta manera:

$method = $_SERVER[''REQUEST_METHOD'']; $request = split("/", substr(@$_SERVER[''PATH_INFO''], 1)); switch ($method) { case ''PUT'': ....some put action.... break; case ''POST'': ....some post action.... break; case ''GET'': ....some get action.... break; case ''DELETE'': ....some delete action.... break; }

OK, concedido: no sé mucho sobre servicios web (todavía). Pero, ¿no sería más fácil simplemente aceptar el objeto JSON a través de POST o GET regulares (que contendrían el nombre del método y todos los parámetros) y luego responder también en JSON. Podemos serializar / deserializar fácilmente a través de json_encode() y json_decode() y hacer lo que queramos con esos datos sin tener que lidiar con diferentes métodos de solicitud HTTP.

¿Me estoy perdiendo de algo?

ACTUALIZACIÓN 1:

Ok, después de investigar varias API y aprender mucho sobre XML-RPC , JSON-RPC , SOAP , REST , llegué a la conclusión de que este tipo de API es sólida. En realidad, el intercambio de stack es más o menos el uso de este enfoque en sus sitios y creo que estas personas saben lo que están haciendo Stack Exchange API .

¿Me estoy perdiendo de algo?

Sí. ;-)

Este fenómeno existe debido a la restricción de interfaz uniforme . A REST le gusta usar estándares ya existentes en lugar de reinventar la rueda. El estándar HTTP ya ha demostrado ser altamente escalable (la web funciona por un tiempo). ¿Por qué deberíamos arreglar algo que no está roto?

Nota: La restricción de interfaz uniforme es importante si desea desacoplar a los clientes del servicio. Es similar a definir interfaces para clases para desacoplarlas entre sí. De c. aquí la interfaz uniforme consiste en estándares como HTTP , tipos MIME , URI , RDF , vocabs de datos enlazados , hydra vocab , etc.

En lo que respecta al uso de la extensión para definir el tipo de datos. Noté que la API de MailChimp lo está haciendo, pero no creo que sea una buena idea.

GET /zzz/cars.json/1 GET /zzz/cars.xml/1

Mi sonido parece una buena idea, pero creo que el enfoque "anterior" es mejor: usar encabezados HTTP

GET /xxx/cars/1 Accept: application/json

También los encabezados HTTP son mucho mejores para la comunicación de tipo de datos cruzados (si alguna vez alguien lo necesitaría)

POST /zzz/cars Content-Type: application/xml <--- indicates we sent XML to server Accept: application/json <--- indicates we want get data back in JSON format

En resumen, REST enfatiza los nombres sobre los verbos. A medida que su API se vuelve más compleja, agrega más cosas, en lugar de más comandos.

Esta es una pregunta de seguridad y mantenimiento.

métodos seguros

Siempre que sea posible, debe usar métodos ''seguros'' (unidireccionales) como GET y HEAD para limitar la vulnerabilidad potencial.

métodos idempotentes

Siempre que sea posible, debe usar 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.

Source

La buena semántica es importante en la programación.

Utilizar más métodos además de GET / POST será útil porque aumentará la legibilidad de su código y lo hará más fácil de mantener.

¿Por qué?

Porque sabes que GET recuperará datos de tu API. Usted sabe que POST agregará nuevos datos a su sistema. Sabes que PUT hará actualizaciones. ELIMINAR eliminará filas, etc., etc.

Normalmente estructurar mis servicios web RESTFUL para que tenga una función de devolución de llamada llamada lo mismo que el método.

Uso PHP, entonces uso function_exists (creo que se llama). Si la función no existe, tiro un 405 (MÉTODO NO PERMITIDO).

La idea de transferencia de estadísticas de RE no se trata de acceder a los datos de la manera más simple posible.

Usted sugirió usar solicitudes 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 ve una solicitud en REST, debe ser inmediatamente lo que está sucediendo con los datos.

Por ejemplo:

GET: /cars/make/chevrolet

es probable que regrese una lista de autos Chevy. Una buena api REST podría incluso incorporar algunas opciones de salida en la cadena de consulta, como ?output=json o ?output=html que permitiría al usuario decidir en qué formato debería codificarse la información.

Después de pensar un poco acerca de 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 Una extensión de archivo faltante se predeterminaría a cualquier formato predeterminado (como JSON); una extensión de archivo que no es compatible podría devolver un código de estado 501 Not Implemented .

Otro ejemplo:

POST: /cars/ { make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

Es probable que cree un nuevo chevy malibu en el db con los colores asociados. 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 accesodores y mutadores para una estructura de base de datos).

Ahora tenemos que pasar al tema de la idempotence . Por lo general, REST implementa CRUD través de HTTP. HTTP usa GET , PUT , POST y DELETE para las solicitudes.

Una implementación muy simplista de REST podría usar el siguiente mapeo CRUD:

Create -> Post Read -> Get Update -> Put Delete -> Delete

Existe 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 diferentes estados de 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

podría ser implementado como:

Post: /cars/oldest?action=delete

Mientras

Delete: /cars/id/123456

dará como resultado el mismo estado de servidor si lo llama una vez, o si lo llama 1000 veces.

Una mejor forma de manejar la eliminación del elemento oldest sería solicitar:

Get: /cars/oldest

y use la ID de los datos resultantes para hacer una solicitud de delete :

Delete: /cars/id/[oldest id]

Un problema con este método sería si se agregaba otro elemento /cars entre cuándo /oldest se solicitó y cuándo se emitió la delete .

Bill Venners: en su publicación de blog titulada "Por qué falló el REST", dijo que necesitamos los cuatro verbos HTTP -GET, POST, PUT y DELETE- y lamentamos que los proveedores de navegadores solo obtengan GET y POST ". ¿Por qué necesitamos los cuatro? verbos? ¿Por qué no son GET y POST suficiente?

Elliotte Rusty Harold: Hay cuatro métodos básicos en HTTP: GET, POST, PUT y DELETE. GET se usa la mayor parte del tiempo. Se usa para cualquier cosa que sea segura, que no cause ningún efecto secundario. GET se puede marcar, almacenar en caché, enlazar y pasar a través de un servidor proxy. Es una operación muy poderosa, una operación muy útil.

POST por contraste es quizás la operación más poderosa. Puede hacer cualquier cosa. No hay límites en cuanto a lo que puede suceder, y como resultado, debes ser muy cuidadoso con eso. Usted no lo marca. No lo guardas en la caché. Usted no lo busca previamente. No hace nada con un POST sin preguntarle al usuario. ¿Quieres hacer esto? Si el usuario presiona el botón, puede PUBLICAR un poco de contenido. Pero no mirará todos los botones de una página y comenzará a presionarlos aleatoriamente. Por el contrario, los navegadores pueden mirar todos los enlaces de la página y recuperarlos previamente, o buscar previamente aquellos que creen que es más probable que sean seguidos. Y, de hecho, algunos navegadores y extensiones de Firefox y varias otras herramientas han intentado hacer eso en un momento u otro.

PUT y DELETE están en el medio entre GET y POST. La diferencia entre PUT o DELETE y POST es que PUT y DELETE son * idempotent, mientras que POST no lo es. PUT y DELETE se pueden repetir si es necesario. Supongamos que intenta subir una nueva página a un sitio. Supongamos que desea crear una nueva página en http://www.example.com/foo.html , por lo que debe escribir su contenido y PONERLO en esa URL. El servidor crea esa página en esa URL que usted proporciona. Ahora, supongamos que por alguna razón su conexión de red se cae. No está seguro, ¿la solicitud fue aprobada o no? Tal vez la red es lenta. Quizás hubo un problema con el servidor proxy. Por lo tanto, está perfectamente bien intentarlo de nuevo, o de nuevo, tantas veces como desee. Debido a que PONER el mismo documento en la misma URL diez veces no será diferente de ponerlo una vez. Lo mismo es cierto para DELETE. Puedes BORRAR algo diez veces, y eso es lo mismo que borrarlo una vez.

Por el contrario, POST, puede causar que algo diferente suceda cada vez. Imagina que estás saliendo de una tienda en línea presionando el botón de comprar. Si vuelve a enviar esa solicitud POST, podría terminar comprando todo en su carrito por segunda vez. Si lo envía de nuevo, lo ha comprado por tercera vez. Es por eso que los navegadores tienen que tener mucho cuidado al repetir las operaciones POST sin el consentimiento explícito del usuario, porque POST puede causar dos cosas si lo haces dos veces, tres cosas si lo haces tres veces. Con PUT y DELETE, hay una gran diferencia entre cero solicitudes y una, pero no hay diferencia entre una solicitud y diez.

Por favor visita la url para más detalles. http://www.artima.com/lejava/articles/why_put_and_delete.html

Actualizar:

Métodos idempotentes Un método HTTP idempotente es un método HTTP que se puede llamar muchas veces sin resultados diferentes. No importaría si el método se llama solo una vez o diez veces más. El resultado debería ser el mismo. De nuevo, esto solo se aplica al resultado, no al recurso en sí mismo. Esto aún se puede manipular (como una marca de tiempo de actualización, siempre que esta información no se comparta en la representación de recursos (actual).

Considere los siguientes ejemplos:

a = 4;
a ++;

El primer ejemplo es idempotente: no importa cuántas veces ejecutemos esta afirmación, a siempre será 4. El segundo ejemplo no es idempotente. Ejecutar esto 10 veces dará como resultado un resultado diferente al correr 5 veces. Como ambos ejemplos están cambiando el valor de a, ambos son métodos no seguros.

Usted preguntó :

¿no sería más fácil simplemente aceptar el objeto JSON a través de $ _POST normal y luego responder también en JSON?

De Wikipedia en REST :

Las aplicaciones RESTful maximizan el uso de la interfaz preexistente y bien definida y otras capacidades incorporadas proporcionadas por el protocolo de red elegido, y minimizan la adición de nuevas funciones específicas de la aplicación en la parte superior.

Por lo que (algo) he visto, creo que esto se logra maximizando el uso de los verbos HTTP existentes, y diseñando un esquema de URL para su servicio que sea tan poderoso y evidente como sea posible.

Se desaconsejan los protocolos de datos personalizados (incluso si están construidos sobre los estándares, como SOAP o JSON), y deben minimizarse para ajustarse mejor a la ideología REST.

SOAP RPC a través de HTTP, por otro lado, alienta a cada diseñador de aplicaciones a definir un vocabulario nuevo y arbitrario de sustantivos y verbos (por ejemplo, getUsers (), savePurchaseOrder (...)), generalmente superpuestos en el verbo HTTP ''POST''. Esto hace caso omiso de muchas de las capacidades existentes de HTTP, como la autenticación, el almacenamiento en caché y la negociación de tipos de contenido, y puede dejar al diseñador de la aplicación reinventando muchas de estas funciones dentro del nuevo vocabulario.

Los objetos reales con los que está trabajando pueden estar en cualquier formato. La idea es reutilizar la mayor cantidad posible de HTTP para exponer las operaciones que el usuario desea realizar en esos recursos (consultas, administración / mutación, eliminación del estado).

Usted preguntó :

¿Me estoy perdiendo de algo?

Hay mucho más que saber sobre REST y la sintaxis de URI / verbos HTTP. Por ejemplo, algunos de los verbos son idempotentes, otros no. No vi nada sobre esto en tu pregunta, así que no me molesté en intentar bucear. Las otras respuestas y Wikipedia tienen mucha información buena.

Además, hay mucho que aprender sobre las diversas tecnologías de red creadas sobre HTTP que puede aprovechar si está utilizando una API verdaderamente relajante. Comenzaría con la autenticación.