Códigos de Respuesta

7
Códigos de Respuesta: 1xx Mensajes No. Descripción 100 111 Conexión rechazada 2xx Operación Exitosa No. Descripción 200 OK 201-203 Información no oficial 204 Sin contenido 205 Contenido para recargar 206 Contenido parcial 3xx Redirección No. Descripción 301 Mudado permanentemente 302 Encontrado 303 Vea otros 304 No modificado 305 Utilice un proxy 307 Redirección temporal

Transcript of Códigos de Respuesta

Page 1: Códigos de Respuesta

Códigos de Respuesta:

1xx Mensajes

No. Descripción

100 111 Conexión rechazada

2xx Operación Exitosa

No. Descripción

200 OK

201-203 Información no oficial

204 Sin contenido

205 Contenido para recargar

206 Contenido parcial

3xx Redirección

No. Descripción

301 Mudado permanentemente

302 Encontrado

303 Vea otros

304 No modificado

305 Utilice un proxy

307 Redirección temporal

Page 2: Códigos de Respuesta

4xx Error por parte del cliente

No. Descripción

400 Solicitud incorrecta

401 No autorizado

402 Pago requerido

403 Prohibido

404 No encontrado

409 Conflicto

410 Ya no disponible

412 Falló precondición

5xx Error del servidor

No. Descripción

500 Error interno

501 No implementado

502 Pasarela incorrecta

503 Servicio no disponible

504 Tiempo de espera de la pasarela agotado

505 Versión de HTTP no soportado

Page 3: Códigos de Respuesta

POST sin embargo es enviar información desde el cliente para que sea procesada y actualice o agregue información en el servidor, como sería la carga o actualización en sí de una noticia. Cuando enviamos (request) datos a través de un formulario, estos son procesados y luego a través de una redirección por ejemplo devolvemos (response) alguna página con información.

Ambos métodos solicitan una respuesta del servidor y ahí es donde parecen que los conceptos son iguales ya que con ambos se podría lograr los mismos objetivos. Yo podría, aunque estaría mal, enviar por GET ciertos datos en la URL y “actualizar o insertar” información en mi base de datos, pero eso le correspondería al método POST. De la misma manera podría solicitar una página diferente por medio de POST y simplemente mostrarla como respuesta aunque eso debería ser a través de una llamada GET.

Las llamadas GET pueden ser cacheadas (historial del navegador), indexadas por buscadores, agregar los enlaces a nuestros favoritos o hasta pasar una url completa a otra persona para que directamente ingrese a esa página. Con el método POST sin embargo no se puede hacer esto.

Generalmente usamos links para ejecutar llamadas GET ya que la idea del link es simplemente “solicitar” una información (página) al servidor y que sea devuelta como una respuesta. Mientras usamos formularios para actualizar datos de productos, clientes, noticias, etc, también teniendo en cuenta que por el método POST también se puede enviar mucha más cantidad de datos que por GET.

Para entender finalmente la diferencia voy a darles un caso de análisis. Supongamos que tenemos en nuestro sitio ecommerce un listado de productos con un link que agregue ese producto al carrito de compras. Si hacemos que ese link ejecute el método GET, como generalmente lo usamos, usaríamos una URL parecida a esta:www.misitio.com/agregar_item_carrito.php?id=1. Al ser una llamada GET, Google podría indexar esa URL y podría aparecer en el buscador al buscar la palabra carrito. Cuando una persona le diera click automáticamente se ejecutaría esa página y agregaría el item con id 1 al carrito del sitio, lo cual les puedo asegurar que no es la idea ya que el visitante al buscar carrito debería querer simplemente entrar al sitio y no agregar un ítem que ni siquiera sabe cual es. Por lo tanto vemos que para este caso, por más que usemos un link, deberíamos de usar una llamada al método POST por ejemplo como lo usa el framework Symfony así:

1

2

3

<a onclick="f = document.createElement('form'); document.body.appendChild(f);

f.method = 'POST'; f.action = this.href; f.submit();return false;"

href="agregar_item_carrito.php?id=1">Agregar al carrito</a>

Lo que hace este link es muy sencillo, por medio del evento onclick de JavaScript, crea dinámicamente un formulario, le dice que será POST (ya que por defecto sería GET), le asigna la URL del enlace al action del form, envía el formulario y retorna false para no ejecutar el link en sí. Para hacer esto con Symfony simplemente usamos el helper link_to agregando la opción post=true:

Page 4: Códigos de Respuesta

1 <?php echo link_to('Agregar al carrito', 'agregar_item_carrito.php?id=1', 'post=true') ?>

Otro ejemplo sencillo sería cuando en un administrador de noticias tenemos un listado de las noticias con un link “eliminar” para borrarlas una por una (situación muy común en sistemas Web). Deberíamos de hacer esta petición usando POST para no permitir, por seguridad, que esa URL creada sea indexada, enviada a otra persona, guardada en favoritos, ni mucho menos ejecutada por culpa del botón atrás del navegador ya que quedaría cacheada en el historial.

Demos un ejemplo opuesto. Hay casos en los que los formularios de búsquedas al ser enviados por POST van a la página de resultados pero como estas llamadas no son cacheadas en el historial del navegador, no podemos volver usando la tecla atrás del navegador por lo que se suele dejar como llamadas GET a fin de ser cacheadas. Esto lo hacemos simplemente poniendo en el method del form la palabra get en lugar de post.

Page 5: Códigos de Respuesta

Métodos de Petición

La primera línea de una petición contiene los comandos HTTP, conocidos como métodos. Existen varios, pero los más conocidos y utilizados son tres: GET, HEAD y POST.

El método GET se utiliza para recuperar información identificada por un URI por parte de los navegadores. Si el URI se refiere a un proceso generador de datos como un programa CGI, en lugar de él, se devuelven los datos generados por el programa. El método GET también se puede utilizar para pasar una pequeña cantidad de información al servidor en forma de pares atributo-valor añadidos al final del URI detrás de un símbolo de interrogación, ?.

GET /cgi/saludar.pl?nombre=pepe&[email protected] HTTP/1.0

La longitud de la petición GET está limitada por el espacio libre en los buffers de entrada. Por lo que para mandar una gran cantidad de información al servidor ha de utilizarse el método POST.

El método HEAD es idéntico al GET excepto que el servidor no devolverá el cuerpo del mensaje en la respuesta a un método HEAD. Esto es útil para obtener información sobre las entidades implicadas en la petición sin que tengan que transferirse. Sirve para comprobar si los enlaces son válidos o para saber cuando fue la última modificación de la entidad solicitada.

El método POST se refiere normalmente a la invocación de procesos que generan datos que serán devueltos como respuesta a la petición. Además se utiliza para aportar datos de entrada a esos programas. En este caso los pares atributo-valor son incluidos en el cuerpo de la petición separados por ampersand.

POST /cgi/saludar.pl HTTP/1.0Accept: */*

nombre=pepe&[email protected]

De este modo el método POST no sufre de las limitaciones de espacio y puede enviar mucha más información al servidor.