REST API vs SOAP API technology

Las dos arquitecturas primarias para las API son REST y SOAP. Al crear una API, se tienen tres opciones: REST, SOAP, o ambos. Las APIs REST son conocidos por ser fáciles y rápidas para su desarrollo, pero, la solicitud se envía en claro, independientemente del tipo de cifrado utilizado. API SOAP es más compleja, requiere un mayor esfuerzo para generar la respuesta y atender la solicitud, pero permiten una mayor flexibilidad al añadir soporte de espacio de nombres.


APIs REST

Cuando se recibe una petición REST, la información vendrá a través de GET. Como tal, toda la información tendrá que ser una URL codificada durante la transmisión, es probable que se desee descifrarla antes de someterlo a cualquier proceso posterior. Diferentes tipos de solicitudes deben dirigirse a diferentes puntos finales (URLs), se puede utilizar un único script para manejar todas las solicitudes o configurar un servidor web para mapear muchas URLs finales en un único script.


API SOAP

Cuando la solicitud SOAP llega, primero se debe revisar para asegurarse de que cumple con el formato especificado por el documento WSDL. La API SOAP utiliza un único punto final para todas las solicitudes, considere permitir a los desarrolladores utilizar una interface web donde se pueda pegar documentos de solicitud en su totalidad en un formulario, y correrlo en el servidor.

Representational State Transfer, REST

La transferencia de estado de representación (REST), es un estilo de arquitectura de software para sistemas hipermedia distribuidos, tales como la World Wide Web.
El Estilo REST consiste en clientes y servidores. Las solicitudes y respuestas se construyen alrededor de la transferencia de “resources” o recursos y de “representations” o representación de un recurso, normalmente un documento. En un momento, un cliente pude estar en transición entre los estados de aplicación o “rest”, en “rest” es capaz de interactuar con un usuario, pero no crea ninguna carga ni consume recursos.
El cliente comienza a enviar peticiones cuando está listo para la transición a un nuevo estado.
REST puede basarse en otros protocolos de capa de aplicación no solo en HTTP aunque fue inicialmente descrito en este contexto.
REST sobre HTTP trabaja y aprovecha las características ya existentes, permitiéndole realizar funciones adicionales en la red tales como almacenamiento en caché de HTTP y la aplicación de seguridad.


RESTRICCIONES, la arquitectura REST describe las siguientes restricciones:


Cliente-Servidor, clientes y servidores deben estar separados por una interfaz uniforme, no les interesa el almacenamiento o la interfaz del otro.


Stateless, cada solicitud del cliente contiene toda la información necesaria para atenderla y cualquier estado se lleva a cabo en el cliente, esto hace a los servidores más visibles al seguimiento y también los hace más confiables.


Cacheable, como en la World Wide Web, los clientes son capaces de recibir respuestas de la caché.


Sistema de capas, clientes no indican si están directamente conectados al servidor o a intermediarios, servidores puedes mejorar la escalabilidad del sistema permitiendo equilibrio de descarga y caches compartidas, también hacen cumplir políticas de seguridad.


Código de la demanda (opcional), los servidores son capaces temporalmente de ampliar o personalizar la funcionalidad de un cliente mediante transferencia lógica.


Interfaz uniforme, la interfaz uniforme entre clientes y servidores simplifica y separa la arquitectura, que permite a cada parte a evolucionar de forma independiente.


Principios rectores de una interfaz REST

· Identificación de los recursos
· Manipulación de los recursos a través de estas representaciones
· Auto-mensajes descriptivos
· Hipermedia como el motor de la aplicación del estado

El consumo del API de Twitter

Según Wikipedia, Twitter es una red social gratuita y servicio de microblogging que permite a los usuarios enviar actualizaciones (también conocido como tweets), que están basados en mensajes de texto de hasta 140 caracteres. Twitter proporciona su propio conjunto de APIs para consumir sus servicios web y crear mashups que utilizan sus servicios.

ActionScript / Flex

Es una librería de código abierto que comenzó como un proyecto de Twitter, el código de la librería twitterscript ActionScript 3 es una gran ayuda cuando se utiliza la API de Twitter con ActionScript. Es muy fácil de usar, después de descargar TwitterApi.swc e importarlo en su versión de Flash o proyecto Flex, se pueden importar y utilizar sus clases.

JavaScript / HTML

Para JavaScript, la librería TwitterJs permite obtener una lista de los mensajes en su propia página web. Una página web incorpora una segunda página web a través de un contenedor iframe que lleva a cabo la llamada de JavaScript a las API de Twitter.