Deberían llamadas a la API sean GET o POST

Question

me di cuenta de que algunas APIs como el uso de la API de Twitter Consigue métodos para todo, por lo que los parámetros se pasan en la url como esta

http://api.twitter.com/1/statuses/user_timeline.json?screen_name=screenname 

Tengo algunas preguntas y agradecería los comentarios o correcciones:

1. Siempre he pensado que usar GET no es una buena idea y que es mejor usar POST.

2. La API que estoy codificando requiere una clave, y no creo que sea una buena idea enviarla en la URL. Entonces, ¿es posible mezclar los parámetros POST y los parámetros de URL?

3. Otro problema es que he oído URL tienen una longitud máxima, así que supongo que haría salir del camino, o hay una solución

4. El único problema que veo con la POST (y lo que estoy adivinando es por qué un sitio como Twitter fue con GET) es que la solicitud no se puede hacer directamente desde el navegador. Corrígeme si me equivoco en esto.

---

Actualizaciones: Gracias a todos los que me está ayudando a una lluvia de ideas esto. Tengo algunas actualizaciones para aclarar algunos de los comentarios.

1. Cuando estaba hablando acerca de no querer enviar la clave en la URL, lo que quería decir es que no quiero que la clave bookmarked si un usuario fuera a marcar una llamada, no es que yo no' Quiero que la llave quede expuesta. ¿Entonces, por las respuestas, podría enviarlo en el campo de encabezado? ¿Alguna otra opción?

2. Quiero aclarar que cuando dicho poste solicita can't be made from the browser, que debería haber dicho, como en POST requests can't be made from the urlhttp://example.com/api/op.json?param=value. Lo siento, dije mal, debería haber sido más claro.

3. Re ya sea REST o no: he hecho REST antes, con un framework MVC que se hizo cargo de la detección de los verbos y las direcciones URL terminó pareciéndose a example.com/entry/1, o example.com/entry/ y los verbos HTTP se lo controla siendo la operación realizado (crear, actualizar, eliminar, enumerar). Pensé, en sentido práctico, que RESTful era más útil para los datos parecidos a crud (crear entrada, obtener entrada, actualizar entrada, eliminar entrada, mostrar todas las entradas). Entonces, si no necesito suciedad, ¿necesito REST? Mi pregunta: si una llamada simplemente da entrada y devuelve resultados, ¿esta API debe ser RESTful? La URL no se ve RESTful, ¿hay algo más en la implementación que podría hacer que RESTful?

4. En cuanto al tamaño de la URL, ha comentado but if you're seriously concerned about it you probably should rethink your API. GET requests shouldn't be sending that much data to the server. Así que tengo este ejemplo: el usuario desea enviar un archivo grande. En el servidor, no ingresaré el archivo en la base de datos ni lo guardaré (así que de acuerdo con los estándares, no estoy "publicando" datos), pero tal vez lo estoy (estos son ejemplos rápidamente pensados, así que por favor tómelos sin apretar) :

   • (a) leer los metadatos del archivo y devolverlo (en caso de que sea GET o POST), o
   • (b) estoy leyendo los metadatos y la modificación de la metada en el archivo y volver el archivo modificado (debería ser GET o POST).
   • Este es un ejemplo de por qué podría necesitar enviar datos de gran tamaño. La pregunta es: (a) y (b) ¿se consideran operaciones GET o POST? y es por eso que estaba preguntando acerca de la longitud de la URL máximo

Answer 1

Desde el punto de vista del servidor, no importa mucho qué mecanismo se utiliza. La única diferencia significativa en el lado del servidor es que las solicitudes GET generalmente se registran por completo (con parámetros), mientras que los datos de las solicitudes POST generalmente no se registran (pero esta no es una regla para servidores personalizados, que pueden registrar o no registrar nada) .

Además, en muchos casos puede usar GET o POST y el servidor manejará ambos casos de manera correcta y transparente. La mezcla también es posible, y la mayoría de los servidores también lo harán de forma transparente.

Las solicitudes GET son más fáciles de depurar (para desarrolladores web), y tal vez esta fue la razón principal para usarlas. También puedo pensar en que las solicitudes GET sean más fáciles de manejar y menos costosas (pero esto depende de cómo se escribe el código), porque en la solicitud GET todo se pasa en el encabezado y CRLFCRLF es un separador de solicitudes (con POST es necesario realizar un análisis adicional del cuerpo).

Las URL tienen un máx. longitud (4K es un límite común, pero no obligatorio), sí. Algunos proxies y algunos servidores (y tal vez algunos clientes) podrían no ser capaces de manejar URL más grandes o tener una restricción artificial (para evitar ataques).

No estoy seguro de haber entendido su idea sobre "la solicitud no se puede realizar directamente desde el navegador". Cuando rellena un formulario web en el navegador, se envía por correo al servidor (a menos que se emplee JavaScript o AJAX, porque al usarlos puede tener una solicitud GET).

Answer 2

1. Siempre he pensado que usar GET no es una buena idea y que es mejor usar POST.

Use GET para leer información, POST para escribir información. Las solicitudes GET no deben modificar el estado del servidor, mientras que las solicitudes POST pueden hacerlo con seguridad. En general, use GET para lecturas y POST para escrituras. Su API probablemente debería usar una combinación de ambos, dependiendo de qué hace cada llamada API específica.

2. La API que estoy codificando requiere una clave, y no creo que sea una buena idea enviarla en la URL. Entonces, ¿es posible mezclar los parámetros POST y los parámetros de URL?

El envío de datos a través de POST no agrega ningún nivel de seguridad en absoluto. Las solicitudes GET no son menos inseguras que las solicitudes POST; ellos son idénticos Para transferir datos privados, use SSL.

3. Otro problema es que he oído URL tienen una longitud máxima, así que supongo que haría salir del camino, o hay una solución

No hay longitud máxima URL definida por el estándar HTTP, aunque some browsers impone uno. Probablemente esto no importe al generar solicitudes GET a través de JavaScript, pero si está muy preocupado por ello, probablemente deba reconsiderar su API. Las solicitudes GET no deberían enviar esa cantidad de datos al servidor.

4.El único problema que estoy viendo con POST (y que supongo es por qué un sitio como Twitter fue con GET) es que la solicitud no se puede realizar directamente desde el navegador. Corrígeme si me equivoco en esto.

Su navegador puede generar solicitudes POST con la misma facilidad que las solicitudes GET, simplemente es más difícil enviar solicitudes POST a través de la barra de direcciones.

Answer 3

La respuesta más completa es: Lea acerca de REST y los verbos HTTP en general.

Estas son algunas respuestas cortas a sus preguntas:

siempre pensé que el uso de GET no es una buena idea y que es mejor que la POST uso.

Depende de lo que esté haciendo.

La API Estoy de codificación requiere una clave, y no creo que sea una buena idea enviar en la URL. Entonces, ¿es posible mezclar los parámetros POST y los parámetros URL ?

Sí, es posible. Sin embargo, no habrá realmente una gran diferencia de seguridad entre enviarlo a través de la URL frente al cuerpo de la solicitud.

Otro problema es que escucho URL tener una longitud máxima, así que supongo que haría salir del camino, o es Hay una solución alternativa

La "solución" es use otros verbos como POST o PUT para transmitir grandes cantidades de datos.

El único problema que veo con el poste (y que supongo es la razón por un sitio como Twitter fue con GET) es que la solicitud no puede hacerse directamente desde el navegador . Corrígeme si estoy mal en esto.

peticiones POST se pueden hacer directamente desde el navegador mediante el uso de un simple HTML <form> con method="POST".

Answer 4

Como dijo Anon, obtenga para recuperar datos, publicar para hacer cambios/enviar datos, lo que lo mantiene alineado con el estándar http. AFAIK, no puedes mezclar los parámetros GET/POST. Puede realizar una solicitud desde un navegador mediante un formulario, pero no ingresando una URL con información en la barra de direcciones. Una clave en la cadena get contra la cadena posterior no es muy diferente. Si la solicitud se intercepta en tránsito, la clave queda comprometida de cualquier manera. Si usa un par de claves pública/privada para encriptar la clave, entonces puede resolver ese problema. Y sí, la cadena GET tiene una longitud máxima, pero también lo hace la publicación, aunque mucho más grande y depende de la configuración de su servidor.

Answer 5

¿Por qué no admite ambos? Es el más flexible. Solo he escrito una API (varias versiones) y hacer que sea compatible con GET y POST para todas las variables ha sido útil tanto para implementar el cliente como para la depuración. Es compatible con mezclar y combinar GET y POST. Use $ _REQUEST y termine.