Mi lista de blogs

jueves, 24 de febrero de 2011

COMENTARIO DE AVANCE

El día de ayer y hoy nos reunimos para poder indagar mas acerca sobre aplicaciones o funciones sobre html, hemos avanzado un poco mas sobre las ventanas que proximamente podremos mejorar con otro tipo de aplicaciones......

De igual forma estamos casi listos para la presentcion del prototipo para el lunes.......

Comentario RED-X

el dia de ayer y hoy nos juntamos para seguir trabajando sobre la pagina,estuvimos buscando e investigando sobre como mejorar la interfaz de nuestra pagina, pero sobre todo como hacer que nuestra pagina cumpla con todos los requerimientos,para que al momento de utilizarlo tenga lo necesario para los usuarios,estuvimos investigando sobre las paginas de internet que dan este servicio, como NIRVANA Y FACILE THINGS,estuvimos checando su interfaz y como es su funcionamiento el cual tambien nos dio algunas ideas de como mejorar nuestra pagina.

martes, 22 de febrero de 2011

COMENTARIO DE LA CLASE

Durante la clase avansamos mas sobre la pagina, y el profesor nos mostro una pagina para poder agregar pdf, con el fin de saber lo que haremos en la proxima unidad. También nos dio el tema de exposicion de la unidad siguiente las exposiciones empesaran el dia martes, haremos lo mismo que en esta unidad, subir la presentación y documentarlo en word.

Mientras tanto dentro de nuestro equipo nos reunimos para poder aprender o recordar en algunos casos el como personalizar los botones,  el seleccionar el fondo de nuestra pantalla, personalizar otro tipo de acciones dentro de la pagina.

Moraleja del día: " si hay dudas, investiga si no le entiendes o no encuentras preguntar al profesor"





lunes, 21 de febrero de 2011

COMENTARIO DE LA CLASE

hoy trabajamos con el enlace de las paginas, también creamos dos paginas en las que se muestra el registro de usuario individual y el registro de un grupo, edgar llego un poco tarde mientras que manuel y yo (adriana) pues nos pusimos a investigar como enlasar varias paginas a una misma.

hoy terminaron de pagar el acces point, el profesor siguio revisando los avances de proyecto. también nos ayudo a saber como enlazar las paginas.

hoy nos reunimos para seguir trabajando con las ventanas del gtd

viernes, 18 de febrero de 2011

Comentario de la clase

el dia de hoy al maestro nos estuvo explicando sobre el proyecto de nuestros compañeros, el proyecto de transito y movilidad estudiantil,en una presentacion que utilizo el maestro defio las ventanas y los tipos de tramites y que se van a poder hacer con su proyecto.
tambien explico los pasos a seguir de los que vayan a utilizar este sistema, tanto los alumnos, como los profesores o los que avaluen las materias que ya cursaron los alumnos, interesados.

el maestro tambien explica sobre el otra tema GTD. nos explica la interfaz del facilie things,como se utiliza, asi como sus ventajas y desventajas, a nossotros nos intereso mucho por uqe nos ofrecio un panorama sobre algunos errores que pudieramos tener conforme avancemos en el proyecto.

jueves, 17 de febrero de 2011

Comentario de la clase

hoy les toco el turno a nuestros compañeros, que les toco el proyecto de transito y movilidad, cada equipo como el dia de ayer, paso a mostrar y explicar su diagrama y su prototipo de la pagina, puduimos ver que a muchos les falta todavia en cuanto a definir bien su proyecto, tambien ay otros que ya su diseño empiza a tomar una forma y estructura clara.

tambien hubieron algunos problesmas de incompatibilidad, un equipo al mostrar su pagina se mostraban los botones, por que no es compatible con el internet explorer.
el maestro nos comento que tambien ay que cuidar esos detalles,para que nuestra pagina se vea en cualquier servidor.
por ultimo el maestro nos mostro la interfaz y el funcionamianto de una pagina GTD que ay en la red,nirvanahg,nos mostro como agregar tareas,quitarlas etc,

miércoles, 16 de febrero de 2011

Comentario de clase

Hoy se mostro al grupo el avance de los proyectos, en nuestro caso nos toco el GTD y solo mostramos las primeras 2 paginas como prototipo, de igual manera mostramos nuestro diagrama usando como apoyo las diapositivas de power point que fu un tip que le profesor no recomendo y que nos facilita la creacion de la interfaz. Tambie mostramos el proyecto 2 que era usar diversas etiquetas en una unica pagina web, fue muy grato observar como los otros equipos utilizaron de manera diferente sus eriquetas, asi como observar las otras interfaces de los equipos que trabajaran con el GTM..

Se nos reconmendo leer mas hacerca del GTM ya que teniamos un concepto erroneo sobre el mismo ya que lo tratabamos como una agenda y no se maneja como tal.

"El sabio es aque que estando en un lugar oscuro no teme adentranse para descubrir que hay dentro, mientras que el ignorante solo se queda estancado en la parte alumbrada."


martes, 15 de febrero de 2011

COMENTARIO DE LA CLASE

Hoy estuvimos trabajando con el diagrama para el desarrollo de nuestro proyecto, el profesor dio la idea o tip de poder hacer el diagrama en power point indicando que cada cuadro del diagrama sera una hoja, de igual forma nos conectamos a la red para poder observar el avance de los demas equipos.
Durante la clase el profesor reviso el avance con las paginas web, esto para el cascaron de nuestro proyecto, subio las fechas de revision y la siguiente actividad...
Por otro lado mi equipo pudo mostrarse a la red y empesamos a trabajar con el diagrama y seguir agregandole mas cosas a la pagina web...
nos hemos dado a la tarea de leer sobre html para poder avanzar con la pagina. Un ejemplo de lo que nosotros haremos es el siguiente:

lunes, 14 de febrero de 2011

sábado, 12 de febrero de 2011

UNIDAD 1- TAREA 4

DESCRIBCION DEL PROYECTO
Se trata de crear una aplicación web, dedicada ala organización de actividades en grupo. GTD es el nombre que tiene este tipo de aplicación y significa (Get Thigs Done) team work (eqeuipo de trabajo). Tiene como finalidad tener información actualizada de un grupo o equipo con el fin de llevar acabo las tareas o proyectos de una institución o incluso personales.

OBJETIVO GENERAL
El objetivo es que durante lo que dura el curso, ay que ir desarrollando la aplicación, paso a paso, asta tener una dirección web donde se pueda organizar todo este tipo de actividades, asi como tener siempre presentes las tareas por hacer, cabe mencionar que uno de los objetivos mas significativos es poder usar estas aplicaciones en nuestro instituto para mejorar y agilizar las tareas y proyectos que este tenga por hacer

OBJETIVOS ESPECIFICOS
Dentro de los objetivos específicos de esta aplicación es que debe cumplir con todos los requerimientos para poder llevar un buen control de actividades, tener una buena interfaz, así como también un buen diseño. Pero muy por encima de eso la aplicación debe ser entendible y fácil de manejar, que el usuario (s) de esta, puedan aprender a manejarlo rápido, y de una forma sencilla, pero que también sea muy completa. Para que el usuario (s), tengan opciones dentro de la aplicación.

ALCANSES
La aplicación debe ser la más completa posible, donde los usuarios puedan tener un sin número de herramientas posibles para trabajar en ella.
Nuestra meta personal es que nuestra aplicación sea la mejor y pueda ser utilizada por la administración de nuestro instituto (ITVH).

JUSTIFICACIONES
La necesidad de tener siempre una lista de tares o actividades bien organizadas, es lo que nos a llevado a crear esta aplicación, muchas veces este tipo de actividades como muchas otras importantes, por una mala planeación o manejo, quedan rezagadas o muchas veces hasta olvidadas.
Muchas veces también se debe ala falta de planeación o por que no se le da el tiempo necesario para llevarla a cabo, quedan inconclusas, o sin hacer, esto es lo que nos lleva a esta idea y hacer esta aplicación. Para tener sobre todo una buena organización y planeación entre los usuarios, y evitar dejar actividades inconcluso, esto también agilizaría en tiempo y forma las actividades y repartiría responsabilidades a quien corresponda.
Este es un ejemplo de una áplicacion web,(GTD)encontrada en la red.

comentario al tema EVOLUCION Y DESARROLLO DE APLICACIONES WEB

La explicacion del quipo mel estuvo bien.su material de trabajo tambien estuvo muy bonito y acorde al tema, definieron bien los conceptos y se distribuyeron bien los temas ala hora de exponer. dieron tambien muchos ejemplos claros de aplicaiones claras y consisas. tambien nos gusto que dieron al gunos ejemplo de como fue el inicio de las aplicaciones web. comentaron que al p´rincipio solo tenian en su mayoria solo texto e informacion, despues evpluciono y aora estamos an la etapa 5 por desirlo asi de las apliaciones web. nos gusto su explicacion estuvo muy amena y clara

comentario del tema COOKIES

el tema del equipo gantz estuvo bien explicado, por ai entre monentos calleron en repeticiones de lo mismo pero la estuvo bien abordado y creemos que a todos nos quedo claro lo que es, bueno a como ellos lo explicaron son fracmentos de informacion que quedan guardados, y tambien ei diferentes tipos de cookies

comentario al tema PROTOCOLO HTTP

el equipo lo explico bien aunque su material creeomos que les falto un poco mas imagenes o ejemplos mas claros de lo que es, y adaptado al tema, las definiones que ellos dieron estuvieron bien segun nuestra apraciasion, pero hubiera estado mejor si ellos dieran ejemplos de como y trabaja y se implementa

comentario del tema HTML COMO UN TIPO SGML
la exposicion estuvo bien solo les falto un poco mas de informacion y definir bien algunos canceptos, asi como dar algunos ejemplos hacerca del tema, alguno de los conceptos que les falto definir fue como el BODY.sin embargo la explicacion estuvo entendible.

camentario del tema arquitectura WWW

el tema estuvo bien desarrollado a nuestro pareser, nos gusta por que explicaon bien el tema y lo fundamantaron bien tambien, el equipo blog web tuvo una buena explicacion y definio bien los terminos esxplico el nombre de la arquitectura WWW, asi como tabien explicolo que significa y para que sirve y cual es su funcion.su material tambien estuvo bien

comentarios del temas URL´S

La exposicion nos parecio buena el equipo explico los terinos y desgoloso muy bien el tema, dieron una definion de lo que son las URL´S y aparte de sus comentarios y tambien dieron ejemplo claros y explisitos,tambien nos parecio muy bien las diapositivas pues tenian imagenes y eran claras y muy acordes al tema
bien por chicos che...

viernes, 11 de febrero de 2011

RELACIONES Y DIFERENCIAS DE HTML, SGML Y XML

Primero que nada es importante saber cada una de las características de los lenguajes.

SGML

Características
ü  Los elementos de contenidos están identificados a través de marcas
ü  Permite la creación de marcas definidas según las necesidades planteadas
ü  El estándar SGML contiene reglas generales para describir tipos específicos de documentos

HTML

Características
ü  Publica los documentos en línea con encabezado texto, tablas, listas etc.
ü  Recupera información en línea vía links de hipertexto
ü  Mejores formularios, claves de acceso, agrupamiento de control
ü  Entre muchos otros

XML

Características
ü  Reglas fáciles de seguir para crear un lenguaje de marcas
ü  Las marcas no tienen un significado determinado
ü  Transmite contenido y estructura

RELACIONES ENTRE LOS TRES

Después de haber conocido las características principales del HTML, SGML y XML se pueden notar ciertas similitudes entre los tres ya que del SGML surgen los otros dos.

Algunas relaciones notorias entre los tres serian principalmente como ya se menciono que del  SGML se originan los otros dos y este describe miles de documentos.

HTML es un lenguaje de la web a si como un tipo de documento SGML, mientras que XML es una versión abreviada de SGML y por tanto permite definir tipos de documentos a si como posibilita la creación de aplicaciones además omite las complejidades del SGML sin perder poder.

DIFERENCIAS ENTRE LOS TRES

Entre las diferencias que se encontraron tomando en cuenta estos tres lenguajes podemos mencionar:
HTML es un descendiente de SGML (como ya se avia mencionado)pues sigue las especificaciones de SGML sin embargo esa también es una gran diferencia porque no realiza ni desarrolla lo mismo que el SGML.

XML al ser igual descendiente del SGML se considera un lenguaje sin embargo no necesariamente se le considera un lenguaje sino más bien una manera de definir lenguajes para diferentes necesidades.

En conclusión podríamos decir que el XML Y HTML son mejoras o descendientes del SGML, los antes mencionados son considerados lenguajes de hipertexto pero que van muy ligados para la programación y diseño de los sitios web que conocemos actualmente.

Bibliografía

TABLA DE DIFERENCIAS ENTRE HTML, XML Y SGML


HTML
XML
SGML


ha sido concebido para mostrar información, determinar como actúa y que hace. Su función radica en ayudarnos a darle formato a los diversos contenidos de una página.


es un lenguaje que fue concebido para describir información. Su función principal es ayudarnos a organizar contenidos y eso hace que los documentos XML sean portables hacia diferentes tipos de aplicaciones.






es una especificación de lenguajes de marcas de carácter general.
EL HTML HA SIDO CREADO PARA DARLE FORMATO A LOS CONTENIDOS DE UNA PAGINA, POR OTRO LADO EL XML SIRVE PARA DESCRIBIR INFORMACIÓN Y EL SGML  SOLO ESPECIFICA DENTRO DEL LENGUAJE MARCAS DE CARACTERES A COMPARACION DEL XML ESTE TIENE FUNCIONES MAS AVANZADAS

sábado, 5 de febrero de 2011

COMENTARIO DE PERSPECTIVA HISTORICA DEL INTERNET

sin duda alguna en todo el transcurso de la carrera hemos aprendido la historia del internet, donde nos han mensionado que internet significa o es conocida como " la red de redes", de igual forma he aprendido que fue creada por el ARPA, que desde aqui fue un nombrado como ARPANET; comprendi que su proposito general o por el cual fue creado es solo con fines de informacion especifica, sin embargo a estas fechas a cambiado ese objetivo en lo personal pienso que su objetivo actual es solo de informacion general y conocimiento mundial.
Otras de las cosas mencionadas en la exposicion fue el PROTOCOLO DEL INTERNET que significa protocolo de transferencia de datos o hipertexto, pues en lo que a mi consierne es el mas utilizado o popular en este medio, existen diferentes versiones algo que sinceramente no sabia sin embargo es importe pues quiere decir que no solo el internet por naturaleza se actualiza sino tambien sus protocolos y modelos, su funcion en si es que los archivos expuestos puedan estar en varios lugares a la vez, es decir que se transfieran sin demora alguna, este protocolo esta aunado a varios archivos en especial al HTML que pues sin mas es el que codifica paginas de internet al igual que drenweaver y otros.

Este protocolo esta de alguna manera decir dividido en dos partes:

SOLICITUD esta asu ves se divide en otros como lo es la linea de solicitud, campos del encabezado y su cuerpo segun esto un ejemplo seria "GET http://es.kioskea.net HTTP/1.0 Accept : Text/html If-Modified-Since : Saturday,15-January-2000 14:37:11 GMT User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)"

RESPUESTA: esta conformado por linea de estado, campo del encabezado y cuerpo un ejemplo seria "HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : Microsoft-IIS/2.0 Content-Type : text/HTML Content-Length : 1245 Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT "

SP yo no sabia que significaba enter increible ahora lo se ^_^

comentario hecho por adriana arenas

jueves, 3 de febrero de 2011

Para que sirve la codificación MIME

MIME es acrónimo de "Multipurpose Internet Mail Extensions Encoding",  un estándar utilizado en Internet con dos finalidades: de un lado, normalizar el intercambio de todo tipo de archivos (texto, audio, vídeo, etc) en la Red; de otra, acabar con el problema de las transferencias de texto internacional por e-mail.

Aunque la descripción detallada del sistema MIME se saldría del propósito de estos apuntes, señalaremos que su funcionamiento se basa en:

 1.-  Clasificar los contenidos a transmitir según diversos tipos.
 2.-  Establecer que acción se toma para cada tipo de fichero que se transmite. Es decir, que tipo de codificación debe utilizarse para cada fichero.

En lo que se refiere al correo electrónico, una de las características principales de los sistemas de codificación MIME es que se han diseñado de forma que se mantenga sin modificación la mayor parte posible de texto (todos los caracteres que sean US-ASCII se transmitan sin modificación), solo son codificados aquellos caracteres "no estándar" que puedan tener problemas en alguna parte del sistema Internet.  De esta forma, si algún agente de correo no es conforme a MIME, el texto codificado todavía tendrá algún sentido (lo que ocurre cuando recibimos, o nos dicen que reciben, esos caracteres extraños intercalados en nuestros correos).

Los sistemas MIME de codificar (encode) no ASCII en US-ASCII son los siguientes:

·         7bit.  El utilizado por defecto.  Significa que el fichero es solo texto ASCII.  Las lineas deben ser "cortas", de 100 caracteres o menos, terminando con el par de caracteres "Retorno de carro" y "Nueva linea" CR-LF "Carriage Return - Line Feed"  (un arcaísmo de cuando se utilizaban Teletipos).

·         Quoted-printable.  Utilizado por texto que es mayoritariamente US-ASCII (7 bit) pero con un pequeño porcentaje de caracteres "extraños" (8 bit).  Este es el caso típico del Español Castellano (ISO-8859-1) y otros idiomas occidentales, cuyos juegos de caracteres caen dentro de la categoría ISO-8859-n.

En esta codificación, cada carácter de 8-bits es codificado en tres caracteres de 7 bits, el primero el signo igual (=) y el valor hexadecimal del carácter.  Por ejemplo, el controvertido carácter "ñ", "F1" en hexadecimal y 11110001 en binario, se codifica como "=F1".  El propio carácter "=" debe ser codificado (=3D) así como el espacio y la tabulación, que son codificados en =20 y =09 respectivamente.  Si una línea termina con "=" seguido del par CR-LF, estos últimos caracteres son ignorados (lo que permite camuflar líneas muy largas).
Las líneas no deben tener mas de 76 caracteres (sin contar los pares CR-LF finales), las más largas pueden ser fragmentadas en el proceso de codificación pero vuelven a unirse en el de decodificación.

·      Base64.  Se utiliza para contenidos que no han de ser leídos por personas o que, por cualquier otra causa, deben ser mantenidos tal-cual.  Cada 3 octetos (24 bits) se codifican en una secuencia de 4 caracteres escogidos de entre un grupo de 64 cuidadosamente seleccionados de entre los US-ASCII que se sabe que tienen menos problemas en las transmisiones.

·      8bit.  Se utiliza cuando se trata de transmitir ficheros con caracteres de 8 bits con líneas "cortas" que terminan en CR-LF.  No es muy usual porque los caracteres de 8 bits no pueden ser enviados con seguridad mediante el estándar SMTP.  Es recomendable no usar transferencias codificadas en 8bit, pues se puede encontrar problemas a la hora de atravesar otras estafetas de correo en Internet y obtener errores como:
.... while talking to cc-server9.massey.ac.nz.:
>>> DATA
<<< 554 8BIT SMTP extension not supported
554 ... Service unavailable
Sin embargo, el nuevo ESMTP (RFC1651) y la extensión RFC1652 pueden manejar mensajes de este tipo.

· binary.  Como el anterior pero sin las terminaciones CR-LF.

¿Qué es un protocolo? y ¿Por qué es necesario?

Un protocolo es un método establecido de intercambiar datos en Internet. Un protocolo es un método por el cual dos ordenadores acuerdan comunicarse, una especificación que describe cómo los ordenadores hablan el uno al otro en una red.

El protocolo determina lo siguiente:
  • El tipo de comprobación de errores que se utilizará.
  • El método de compresión de los datos, si lo hay.
  • Cómo indicará el dispositivo que envía que ha acabado el enviar un mensaje.
  • Cómo indicará el dispositivo que recibe que ha recibido un mensaje.
Si bien los protocolos pueden variar mucho en propósito y sofisticación, la mayoría especifica una o más de las siguientes propiedades:

  • Detección de la conexión física subyacente (con cable o inalámbrica), o la existencia de otro punto final o nodo.
  • Negociación de varias características de la conexión.
  • Cómo iniciar y finalizar un mensaje.
  • Procedimientos en el formateo de un mensaje.
  • Qué hacer con mensajes corruptos o formateados incorrectamente (corrección de errores).
  • Cómo detectar una pérdida inesperada de la conexión, y qué hacer entonces.
  • Terminación de la sesión y/o conexión.

Conmutación de Paquetes

Se denomina Conmutación de Paquetes (Packet Switching en inglés) al establecimiento, por parte de una red de comunicaciones de un intercambio de bloques de información (o “paquetes”) con un tamaño específico entre dos puntos, un emisor y un receptor. En el origen, extremo emisor, la información se divide en “paquetes” a los cuales se les indica la dirección del destinatario. Esto es, cada paquete contiene, además de datos, un encabezado con información de control (prioridad y direcciones de origen y destino).

Debido al auge de las transmisiones de datos, la conmutación de circuitos es un sistema muy ineficiente ya que mantiene las líneas ocupadas por mucho tiempo aun cuando no hay información circulando por ellas. Además, la conmutación de circuitos requiere que los dos sistemas conectados trabajen a la misma velocidad, cosa que no suele ocurrir hoy en día debido a la gran variedad de sistemas que se comunican.

En conmutación de paquetes, los datos se transmiten en paquetes cortos. Para transmitir grupos de datos más grandes, el emisor trocea estos grupos en paquetes más pequeños y les adiciona una serie de bits de control. En cada nodo, el paquete se recibe, se almacena durante un cierto tiempo y se transmite hacia el emisor o hacia un nodo intermedio.


Las ventajas de la conmutación de paquetes frente a la de circuitos son:

1. La eficiencia de la línea es mayor: ya que cada enlace se comparte entre varios paquetes que estarán en cola para ser enviados en cuanto sea posible. En conmutación de circuitos, la línea se utiliza exclusivamente para una conexión, aunque no haya datos a enviar.

2. Se permiten conexiones entre estaciones de velocidades diferentes: esto es posible ya que los paquetes se irán guardando en cada nodo conforme lleguen (en una cola) y se irán enviando a su destino.

3. No se bloquean llamadas: ya que todas las conexiones se aceptan, aunque si hay muchas, se producen retardos en la transmisión.

4. Se pueden usar prioridades: un nodo puede seleccionar de su cola de paquetes en espera de ser transmitidos, aquellos más prioritarios según ciertos criterios de prioridad.


Técnica de conmutación

Cuando un emisor necesita enviar un grupo de datos mayor que el tamaño fijado para un paquete, éste los trocea en paquetes y los envía uno a uno al receptor.

Hay dos técnicas básicas para el envío de estos paquetes:

1. Técnica de datagramas: cada paquete se trata de forma independiente, es decir, el emisor enumera cada paquete, le añade información de control (por ejemplo número de paquete, nombre, dirección de destino, etc...) y lo envía hacia su destino. Puede ocurrir que por haber tomado caminos diferentes, un paquete con número por ejemplo 6 llegue a su destino antes que el número 5. También puede ocurrir que se pierda el paquete número 4. Todo esto no lo sabe ni puede controlar el emisor, por lo que tiene que ser el receptor el encargado de ordenar los paquetes y saber los que se han perdido (para su posible reclamación al emisor), y para esto, debe tener el software necesario.

2. Técnica de circuitos virtuales: antes de enviar los paquetes de datos, el emisor envía un paquete de control que es de Petición de Llamada, este paquete se encarga de establecer un camino lógico de nodo en nodo por donde irán uno a uno todos los paquetes de datos.

miércoles, 2 de febrero de 2011

TABLA DE MÉTODOS HTTP


Método
Significado
GET
Devuelve el recurso identificado en la URL pedida.
HEAD
Funciona como el GET, pero sin que el servidor devuelva el cuerpo del mensaje. Es decir, sólo se devuelve la información de cabecera.
POST
Indica al servidor que se prepare para recibir información del cliente. Suele usarse para enviar información desde formularios.
PUT
Envía el recurso identificado en la URL desde el cliente hacia el servidor.
OPTIONS
Pide información sobre las características de comunicación proporcionadas por el servidor. Le permite al cliente negociar los parámetros de comunicación.
TRACE
Inicia un ciclo de mensajes de petición. Se usa para depuración y permite al cliente ver lo que el servidor recibe en el otro lado.
DELETE
Solicita al servidor que borre el recurso identificado con el URL.
CONNECT
Este método se reserva para uso con proxys. Permitirá que un proxy pueda dinámicamente convertirse en un túnel. Por ejemplo para comunicaciones con SSL.

MÉTODOS HTTP

MÉTODOS DE PETICION

HTTP define 8 métodos (algunas veces referido como "verbos") que indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinámica, depende de la aplicación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que residen en el servidor.

HEAD
Pide una respuesta idéntica a la que correspondería a una petición GET, pero sin el cuerpo de la respuesta. Esto es útil para la recuperación de meta-información escrita en los encabezados de respuesta, sin tener que transportar todo el contenido.
GET
Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL.
Ejemplo:

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

Ejemplo con parámetros:
/index.php?page=main&lang=es

POST
Somete los datos a que sean procesados para el recurso identificado. Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.
PUT
Sube, carga o realiza un upload de un recurso especificado (archivo), es el camino más eficiente para subir archivos a un servidor, esto es porque en POST utiliza un mensaje multiparte y el mensaje es decodificado por el servidor. En contraste, el método PUT te permite escribir un archivo en una conexión socket establecida con el servidor.
La desventaja del método PUT es que los servidores de hosting compartido no lo tienen habilitado.
Ejemplo:
PUT /path/filename.html HTTP/1.1

DELETE
Borra el recurso especificado.

TRACE
Este método solicita al servidor que envíe de vuelta en un mensaje de respuesta, en la sección del cuerpo de entidad, toda la data que reciba del mensaje de solicitud. Se utiliza con fines de comprobación y diagnostico.


OPTIONS
Devuelve los métodos HTTP que el servidor soporta para un URL específico. Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante petición en lugar de un recurso específico

 
MÉTODO  URI  

El método le indica al servidor que hacer con el URI , por último la versión simplemente indica el número de versión del protocolo que el cliente entiende. Una petición habitual utiliza el método GET para pedirle al servidor que devuelva el URI solicitado:
GET /index.html HTTP/1.0




MÉTODOS DE SEGURIDAD



Ejecutores deben ser conscientes de que el software representa al usuario en sus interacciones a través de Internet, y debe tener cuidado para permitir al usuario estar al tanto de las acciones que podría adoptar medidas que puedan tener una importancia inesperada a sí mismos oa otros.

En particular, la convención se ha establecido que los métodos GET y CABEZA NO DEBE tener la importancia de tomar una acción distinta a la recuperación. Estos métodos deben ser considerados "seguros". Esto permite que los agentes de usuario para representar a otros métodos, como POST, PUT y DELETE, de una manera especial, para que el usuario sea consciente del hecho de que una acción que posiblemente sean inseguras se solicita.

Naturalmente, no es posible garantizar que el servidor no genera efectos secundarios como resultado de realizar una solicitud GET, de hecho, algunos recursos dinámicos en cuenta que una característica. La distinción importante aquí es que el usuario no solicitó los efectos secundarios, por lo tanto, no pueden ser considerados responsables de ellos.


MÉTODOS IDEMPOTENTES


Los métodos también pueden tener la característica de "idempotencia" en que (aparte de las cuestiones de error o de vencimiento) los efectos secundarios de N> 0 peticiones idénticas es el mismo que para una sola petición. Los métodos GET, HEAD, PUT y compartir SUPR esta propiedad. Además, las opciones de métodos y TRACE no debe tener efectos secundarios, por lo que son inherentemente idempotente.

Sin embargo, es posible que una secuencia de varias solicitudes no es idempotente, aunque todos los métodos de ejecución en ese orden son idempotentes. (Una secuencia es idempotente si una sola ejecución de toda la secuencia siempre produce un resultado que no se cambia por un reexecution de todos o parte de esa secuencia.) Por ejemplo, una secuencia no es idempotente si su resultado depende de una valor que luego es modificada en la misma secuencia.

Una secuencia que no tiene efectos secundarios es idempotente, por definición (siempre que no haya operaciones simultáneas se están ejecutando en el mismo conjunto de recursos).