Una RESTful web API también conocida como RESTful Web Services es una web API implementado en HTTP bajo principios de REST. RESTful es una colección de recursos con cuatro aspectos definidos:

• El Uniform Resource Identifier o URI (en español: “identificador uniforme de recursos”) base para la web API es como http://example.com/resources/
• El Internet media type es soportado por la web API. Por lo general para ser consumido con JSON pero puede ser cualquier otro tipo válido de Internet media type siempre y cuando se trate de un hypertext standard válido.
• El conjunto de las operaciones que soportan la web API utilizan métodos HTTP como por ejemplo: GET, PUT, POST, DELETE.
• El API debe ser iniciado por hipertexto.

Los métodos PUT y DELETE son métodos idempotente. El método GET es un método seguro (o nullipotent), lo que significa que la llamada no produce efectos secundarios.

A diferencia de los web services basados ​​en SOAP no existe un estándar oficia para RESTful web API. Esto se debe a que REST tiene una arquitectura a diferencia de SOAP que es un protocolo. A pesar de que el resto no es un estándar. Una aplicación RESTful como la Web puede utilizar estándares como HTTP, URI, XML, etc.

---

WEB SERVICES

En los primeros computadores corría un solo programa a la vez, pero en la medida que en un mismo computador podían correr varios programas al mismo tiempo, surgió la necesidad de contar como mecanismo de comunicación entre ellos, esto se llamó comunicación Task to Task y, este mecanismo ha evolucionado debido que los computadores conforman redes.
Por tanto, esta comunicación debe poder efectuarse entre un programa X, que corre en el computador Alfa, y otro programa Y, que corre en el computador Beta.
Para que esta comunicación funcione, primero debe existir un medio de comunicación entre el computador Alfa y el computador Beta; esto hoy está resuelto con la Internet. Y segundo, el programa X debe saber conversar con el programa X. Para que esto ocurra el programador a cargo de X debe conocer de Y. A su vez el programador a cargo de Y debe conocer de X, por lo menos en los que se refiere al intercambio de datos. Esto hace que si no hay acuerdo entre el programador de X y el programador de Y, no hay comunicación posible.
El potencial de los Web Services está en que el programador de X puede crear un Web Service para transferir datos sin necesidad de conocer al programador Y, ni a los programas que éste tiene a cargo. De modo que quien quiera recibir los datos solo necesita usar el Web Service y punto. Esto significa que pueden existir transferencias de datos entre distintas aplicaciones/programas que funcionan en varios computadores, con distintos sistemas operativos, y que pertenezcan a diferentes empresas o instituciones.
A modo de ejemplo, si Ud. Ha despachado un paquete vía FedEx Express y desea conocer el estado de su despacho, esta empresa pone a su disposición un Web Service.

1.2. ESTANDARES EMPLEADOS

• Web Services Protocol Stack: Así se denomina al conjunto de servicios y protocolos de los servicios Web.
• XML (Extensible Markup Language): Es el formato estándar para los datos que se vayan a intercambiar.
• SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call): Protocolos sobre los que se establece el intercambio.
• Otros protocolos: los datos en XML también pueden enviarse de una aplicación a otra mediante protocolos normales como HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), o SMTP(Simple Mail Transfer Protocol).
• WSDL (Web Services Description Language): Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web.
• UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información de los servicios Web. Permite comprobar qué servicios web están disponibles.
• WS-Security (Web Service Security): Protocolo de seguridad aceptado como estándar por OASIS (Organization for the Advancement of Structured Information Standards). Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.

1.3. VENTAJAS

• Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen.
• Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento.
• Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.

1.4. INCONVENIENTES

• Para realizar transacciones no pueden compararse en su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA (Common Object Request Broker Architecture).
• Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM (Distributed Component Object Model). Es uno de los inconvenientes derivados de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento.
• Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicación entre programas a ambos lados de la barrera.

1.5. RAZONES PARA CREAR SERVICIOS WEB
La principal razón para usar Web Services es que se pueden utilizar con HTTP sobre TCP (Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls-que filtran y bloquean gran parte del tráfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados. Es importante señalar que los servicios web se pueden utilizar sobre cualquier protocolo, sin embargo, TCP es el más común.
Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco conocidas, tales como EDI(Electronic Data Interchange), RPC (Remote Procedure Call), u otras APIs.
Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada.

Ejemplo de un Web Service

1.6. PLATAFORMAS

Servidores de aplicaciones para servicios Web:
• JBoss servidor de aplicaciones J2EE Open Source de Red Hat inc.
• Oracle Fusion Middleware
• IBM Lotus Domino a partir de la versión 7.0
• Axis y el servidor Jakarta Tomcat (de Apache)
• ColdFusion MX de [[Macromedia]httpd ]
• Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat)
• JOnAS (parte de ObjectWeb una iniciativa de código abierto)
• Microsoft .NET
• Novell exteNd (basado en la plataforma J2EE)
• WebLogic
• WebSphere
• JAX-WS con GlassFish
• Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el lenguaje de programación Python
• VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host IBM y VT
• PHP

Source: http://msaffirio.wordpress.com/2006/02/05/%C2%BFque-son-los-web-services/

---

REST: Representational State Transfer

La Transferencia de Estado Representacional (Representational State Transfer) o REST es una técnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

Si bien el término REST se refería originalmente a un conjunto de principios de arquitectura —descritos más abajo—, en la actualidad se usa en el sentido más amplio para describir cualquier interfaz web simple que utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes como el protocolo de servicios web SOAP. Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y también es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas, aunque RPC no es un ejemplo de REST.
Los sistemas que siguen los principios REST se llaman con frecuencia RESTful; los defensores más acérrimos de REST se llaman a sí mismos RESTafaris.

REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños fundamentales clave:
Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes. Sin embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesión (algunas de estas prácticas, como la reescritura de URLs, no son permitidas por REST).

Un conjunto de operaciones bien definidas que se aplican a todos los recursos de información: HTTP en sí define un conjunto pequeño de operaciones, las más importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a las operaciones CRUD que se requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema.
Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es direccionable únicamente a través de su URI.

El uso de hipermedios, tanto para la información de la aplicación como para las transiciones de estado de la aplicación: la representación de este estado en un sistema REST son típicamente HTML o XML. Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional.