LENGUAJES VISUALES II

Docente: Ing. Milciades González Dominguez

Qué es REST
Actualmente, las API REST están realmente de moda: parece que
cualquier aplicación deba proporcionar su “API REST”. Pero... ¿qué
significa realmente una API REST?

REST deriva de "REpresentational State Transfer", que traducido

vendría a ser “transferencia de representación de estado”, lo que
tampoco aclara mucho, pero contiene la clave de lo que significa.
Porque la clave de REST es que un servicio REST no tiene estado
(es stateless), lo que quiere decir que, entre dos llamadas
cualesquiera, el servicio pierde todos sus datos. Esto es, que no se
puede llamar a un servicio REST y pasarle unos datos (p. ej. un
usuario y una contraseña) y esperar que “nos recuerde” en la
siguiente petición.

De ahí el nombre: el estado lo mantiene el cliente y por lo tanto es

el cliente quien debe pasar el estado en cada llamada. Si quiero que
un servicio REST me recuerde, debo pasarle quien soy en cada
llamada. Eso puede ser un usuario y una contraseña, un token o
cualquier otro tipo de credenciales, pero debo pasarlas en cada
llamada. Y lo mismo aplica para el resto de información.
El no tener estado es una desventaja clara: tener que pasar el
estado en cada llamada es, como mínimo, tedioso, pero la
contrapartida es clara: escalabilidad. Para mantener un estado se
requiere algún sitio (generalmente memoria) donde guardar todos
los estados de todos los clientes. A más clientes, más memoria,
hasta que al final podemos llegar a no poder admitir más clientes,
no por falta de CPU, sino de memoria. Es algo parecido a lo que
ocurre con la web tradicional (que también es stateless). Sea cual
sea la tecnología con la que desarrolles para web, seguro que
conoces que puedes crear lo que se llama una “sesión”. Los datos
de la sesión se mantienen entre peticiones y son por cada usuario.
El clásico ejemplo de sesión puede ser un carrito de la compra,
entre las distintas peticiones web, la información del carrito de
compra se mantiene (¡ojo! hay otras alternativas para implementar
carritos de compra).

Por norma general, la sesión se almacena en la memoria RAM del

servidor, por lo que es fácil quedarnos sin memoria si introducimos
demasiados datos en sesión (o tenemos muchos usuarios
simultáneos). Por supuesto, podemos utilizar varios servidores, pero
como bien saben los desarrolladores web, mover la sesión
contenida en memoria entre servidores es generalmente imposible
o altamente ineficiente, lo que penaliza el balanceo de carga, lo que
a su vez redunda en menor escalabilidad y menor tolerancia a
fallos. Hay soluciones intermedias, tales como guardar la sesión en
base de datos, pero su impacto en el rendimiento suele ser muy
grande. De hecho, el consejo principal para desarrollar aplicaciones
web altamenteescalables es: no usar la sesión.

Así pues, tenemos que el ser stateless es la característica principal

de REST, aunque por supuesto no la única. Así, cualquier servicio
REST (si quiere ser merecedor de ese nombre) debería no tener
estado, pero no cualquier servicio sin estado es REST. Hay otros
factores, pero vamos a destacar el que los ingleses llaman “uniform
interface” y es lo que diferencia un servicio web clásico (orientado a
RPC) de un servicio REST.
Uniform interface
Una diferencia fundamental entre un servicio web clásico (SOAP) y
un servicio REST es que el primero está orientado a RPC, es decir,
a invocar métodos sobre un servicio remoto, mientras que el
segundo está orientado a recursos. Es decir, operamos sobre
recursos, no sobre servicios.

En una API REST la idea de “servicio” como tal desaparece. Lo que

tenemos son recursos, accesibles por identificadores (URIs). Sobre
esos recursos podemos realizar acciones, generalmente
diferenciadas a través de verbos HTTP distintos.

Así, en un servicio web clásico (SOAP) tendríamos un servicio

llamado BeerService que tendría un método llamado GetAll que me
devolvería todas las cervezas. La idea, independientemente de la
tecnología usada para consumir el servicio web, es que se llama a
un método (GetAll) de un servicio remoto (BeerService). Del mismo
modo para obtener una cerveza en concreto llamaríamos al método
GetById() pasándole el id de la cerveza. De ahí que se diga que
están orientados a RPC (Remote Procedure Call – Llamada a
método remoto).

Por su parte en un servicio REST la propia idea de servicio se

desvanece. En su lugar nos queda la idea de un “recurso”,
llamémosle “Colección de cervezas” que tiene una URI que lo
identifica, p. ej. /Beers. Así, si invoco dicha URI debo obtener una
representación de dicho recurso, es decir, debo obtener el listado de
todas las cervezas.

Para obtener datos de una cerveza, habrá otro recurso (cerveza)

con una URI asociada. Además, entre los recursos hay relaciones:
está claro que una cerveza forma parte de la “Colección de
cervezas” así que parece lógico que a partir de la colección entera
(/Beers) pueda acceder a uno de sus elementos con una URI tipo
/Beers/123, siendo "123" el ID de la cerveza.
Volvamos a nuestro servicio SOAP: para dar de alta una cerveza
llamaríamos a un método "AddBeer" de nuestro "BeerService", y le
pasaríamos la cerveza a añadir. En cambio, en nuestra API REST
añadir una cerveza consiste en usar la URI de dicha cerveza, (p. ej.
/Beers/456 si estamos añadiendo la cerveza con ID 456) usando
POST o PUT como verbo HTTP y colocando los datos de la cerveza
en el cuerpo de la petición. La URI para acceder a la cerveza con ID
456 es siempre /Beers/456 y es el verbo HTTP (GET, POST, PUT,
DELETE,...) el que indica cual es la operación que deseamos hacer
con esa cerveza.

Métodos del HTTP en REST

En un API REST usamos los métodos del HTTP, existentes desde
siempre en el protocolo aunque hasta ahora infrautilizados en los
sitios web clásicos (aquellos basados en contenido), para indicar el
tipo de operación que vamos a realizar sobre los recursos que nos
ofrecen los servicios web.

Estos métodos también los conocemos como los verbos del HTTP y
son los siguientes:

GET: Para operaciones de consulta de datos. Puedes consultar un

listado de cervezas o consultar una cerveza determinada. Ambas
operaciones serían GET, solo que la consulta al listado se realizaría
sobre el recurso /beer y la consulta a una cerveza sobre el recurso
de una cerveza particular /beer/33 o algo parecido.
POST: Operaciones de inserción
PUT: Para realizar modificaciones
PATCH: Para realizar modificaciones parciales en un recurso
DELETE: Para eliminar un recurso dado.
De este modo, una misma URL, o endpoint, como /beer/77 puede
servir para realizar múltiples operaciones, todo depende del método
de la solicitud HTTP que estamos utilizando.
Como has podido comprobar, los servicios web API REST son
capaces de realizar las operaciones típicas de un CRUD.

REST o simplemente API, o servicio web

Muchas veces se usa el término REST o API REST para referirse a
lo que conocemos como un servicio web, pero no todo servicio web
es REST.

REST es todo un patrón de comportamiento que podemos soportar

de una manera más o menos fiel. No todas las API son REST y
quizás tampoco signifique por ello un problema. Comportarse más o
menos cercano al patrón REST hace que los clientes que van a
usar ese API puedan tener menos sorpresas, pero a veces también
puede resultar un poco limitante y los desarrolladores se pueden
tomar licencias en la implantación de sus servicios web.

API REST de uso público

Existen decenas de API REST o servicios web públicas, que
podrías usar para realizar todo tipo de pruebas y desarrollar
aplicaciones frontend de ejemplo, para aprender un framework o
simplemente para saber cómo se comportan este tipo de
aplicaciones backend.

Arquitectura de un desarrollo basado en API REST

Una vez que sabemos exactamente las características de REST
nos podremos plantear cómo es una aplicación basada en REST.
Realmente podría haber muchas respuestas, puesto que podemos
usar APIs para hacer multitud de sitios web. Por ejemplo, podríamos
usar el API REST de Twitter para crear un servicio basada en esa
red o el API de Youtube para crear un sitio web que muestra vídeos
de distintas maneras. Pero no es eso a lo que me refiero en este
artículo.
En este caso quiero proponer un modelo que aprovecha
perfectamente sus posibilidades de REST donde tú o tu equipo es
el que desarrolla tu propia API y donde tú eres el consumidor de
ella.
Pues bien, ahora en un desarrollo basado en API REST tendremos
un esquema como el que puedes ver en esta imagen:
El cliente inicia siempre una solicitud, pero ahora ésta no la produce
el usuario en "bruto" hacia el servidor, sino que pasa por Javascript.
Nuestro lenguaje del lado del cliente es el que solicitará al servidor
un recurso al servidor.

El servidor y el cliente web se comunican en un formato de

intercambio de información como puede ser JSON, aunque podría
ser otro lenguaje como XML.
Lo importante es que el cliente no recibe HTML para renderizar, sino
simplemente los datos que se han generado como respuesta. Es
decir, el servidor no escribe HTML, sino únicamente genera los
datos para enviarlos al cliente.

¿Qué tecnologías de servidor usas para implementar REST?

Es independiente, podrás tener un servidor que trabaja con PHP,
Java, Python, NodeJS o lo que prefieras, o te imponga el proyecto.
Tanto el lenguaje como la base de datos son importantes, porque
nos sirven para procesar la solicitud y generar la respuesta, pero no
importa cómo lo hagas en el servidor. Simplemente que la
respuesta la entregues en ese lenguaje de intercambio de
información que estés usando, generalmente JSON.

¿Qué librerías JS?

Realmente tampoco estamos obligados a usar ninguna. Lo que
estará claro es que si estás produciendo una web en el cliente
usarás Javascript, pero la librería que tengas para facilitarte las
cosas es indiferente.

Actualmente, por posibilidades, por comunidad y por facilidad de

desarrollo los profesionales se están decantando por AngularJS,
pero realmente usarás aquella con la que te sientas a gusto.

¿Alguna librería del lado del servidor?

Debe haber cientos, también dependiendo del lenguaje que estés
usando en el servidor. Si es con PHP puedes usar Laravel, Symfony
o microframeworks como Slim. Si estás usando NodeJS
probablemente encuentres útil Express o Sails.js. Son solo por
nombrar algunas, puesto que en este caso todo depende mucho de
la tecnología que estés usando en el servidor.
¿Qué tipo de aplicaciones son adecuadas para esta arquitectura?
Esta es una buena pregunta, porque realmente el desarrollo basado
en API REST no es para cualquier tipo de proyecto. Si estás
haciendo un sitio web y planeas que tu sitio va a ser siempre eso
"una web", quizás sea innecesario desarrollar en base a un API. Por
ejemplo, un sitio centrado en contenido, como un blog o una página
de una empresa donde ofrece sus productos, servicios y modos de
contacto, no tiene sentido desarrollarla en base a un API. Ahora, si
lo que estás es ofreciendo un servicio online o estás realizando una
aplicación web de gestión, entonces encaja perfectamente la
filosofía de REST.

En general si piensas que tu sistema en el futuro podría ser

accedido no solo desde una página web, sino también desde una
App para móvil o desde una aplicación de otro tipo, las ventajas de
REST serán especialmente útiles. En resumen, si sospechas que
los datos o servicios que estás ofreciendo en un futuro puedan
llegar a ser consultados desde otros sistemas, te interesa usar
REST. Incluso hay profesionales que piensan que, aunque de
momento no estés pensando en que esos datos o servicios puedan
llegar a ser consultados desde otros sistemas ajenos a tu web,
merece la pena usar REST porque es la solución que mayor
escalabilidad te va a aportar. Todo esto lo verás mejor enseguida
que tratemos las ventajas / inconvenientes.

Ventajas del desarrollo basado en REST

Enumeramos una serie de ventajas que encontrarás en un
desarrollo basado en API REST.

1. separación cliente/servidor
Al ser sistemas independientes (solo se comunican con un lenguaje
de intercambio como JSON) puedes desarrollarlos proyectos
autónomos, equipos autónomos. Al cliente le da igual cómo está
hecha la API y al servidor le da igual qué vas a hacer con los datos
que te ha proporcionado.
Si necesitas evolucionar/refactorizar uno de los dos, back o front, se
puede hacer de manera separada, siempre que se mantenga la
interfaz del API.

Puedes hacer varios front con un único backend (frontal no tiene xq

ser solo web, puede ser un app para Android otro para un App iOS,
etc.)
En este sentido otra ventaja importantísima es la posibilidad de
crear tantos frontales como necesites con la misma API. Igual
comienzas desarrollando una web, pero con la misma API podrás
desarrollar también una aplicación para iOS, Android y si mañana
gustas para Windows 8, Windows Phone, el próximo Windows 10,
Blackberry, FirefoxOS y tantos como vengan en el futuro a encajar
con tu estrategia de negocio.

2. Independencia de tecnologías / lenguajes

Puedes desarrollar en cualquier tipo de tecnología o lenguaje con la
que te sientas a gusto o con la que puedas acortar tus tiempos de
desarrollo, o encaje con la filosofía o necesidades de tu proyecto.
Es indiferente que en el futuro cambies totalmente las tecnologías
con las que está implementado tu API REST, siempre y cuando
respetes "el contrato", osea, que sigas teniendo las mismas
operaciones en el API y hagan las mismas cosas que se supone
que deben hacer.
3. Fiabilidad, escalabilidad, flexibilidad
Al final solo te tienes que preocupar que el nexo cliente / servidor
esté correcto. Puedes hacer cambios en tu servidor, lenguajes,
bases de datos, etc. y mientras devuelvas los datos que toca todo
irá correctamente.

Escalabilidad porque puedes crecer todo lo que necesites en cada

momento. Tu API puede responder a otros tipos de operaciones o
puede versionarse tanto como desees. También tu programación
del lado del cliente puede crecer todo lo necesario con el tiempo,
incluso como decíamos, crear otros frontales, no solo web, también
de Apps para cualquier dispositivo.

A la hora de ejecutar tu aplicación también tienes una flexibilidad

mucho mayor. Las páginas del front las puedes enviar desde unos
servidores y las API pueden estar alojadas en servidores
independientes, tantos como necesites. Por las características de
REST (principalmente no guardar estado) es indiferente qué
servidor atienda cada solicitud, pues es el propio cliente el que tiene
que mandar el estado al servidor, así que el balanceo de carga es
mucho más simple que en aplicaciones tradicionales donde el front
está mezclado con el back. También tienes la aproximación de las
"micro APIs", en las que puedes dividir los procesos en diferentes
servidores que atiendan a diferentes tipos de operaciones del API.

4. Experiencia de usuario
Aunque eso depende más de cómo está hecha la parte del cliente,
teóricamente el desarrollo de sitios web basados en un API puede
dar mejor desempeño que uno tradicional. Cuando haces una
solicitud al servidor lo que tienes como respuesta son datos planos,
que requieren tiempos de transferencia menores que si esos
mismos datos los recibieras mezclados con el HTML/CSS de la
presentación. En este tipo de aplicaciones web no necesitas
recargar la página, aunque esto no es una ventaja específica del
desarrollo basado en REST, sino del uso de Ajax en general, con el
que podemos conseguir aplicaciones web que se asemejan más a
aplicaciones de escritorio

5. REST requiere menos recursos del servidor

Esto no es necesariamente cierto aunque en muchos casos sí se
pueda deducir. Hay muchas opiniones al rededor de REST.
Nosotros basamos esa afirmación en estos motivos:
No mantener el estado, no requiere memoria, se pueden atender
más peticiones
No requiere escribir el HTML, por lo tanto tienes menos
procesamiento en el servidor
Desventajas del desarrollo basado en REST
Tenemos que cambiar el modo de pensar, por lo que los equipos de
trabajo se tienen que reciclar. Todos deben de romper con esa idea
de que todo está en un servidor y que todo está ahí para desarrollar
tus necesidades. En un esquema REST puedes tener varios
servidores donde unos no saben que los otros existen. No sabes si
un usuario ha iniciado sesión en un servidor y si le has enviado
ciertos datos. Tampoco sabes realmente en qué servidor puede
caer una solicitud. Romper con ese esquema de todo está en el
mismo servidor, tengo todas mis clases y todas las partes de mi
aplicación centralizadas es uno de los puntos que pueden resultar
más complicados.

En las API REST no mantenemos estado y eso hace que tengas

que montar una infraestructura propia para poder conservar el
conjunto de la aplicación. Generalmente mandarás un token que
indique quien eres al servidor y qué has realizado ya en tu
aplicación.

En un principio puedes incurrir en mayores tiempos de desarrollo,

porque tienes que montar todo el sistema de tu API. Sin embargo, a
futuro y sobretodo cuando ese API la vas a consumir desde otros
sistemas, puedes recuperar el tiempo adicional dedicado y ganar
mucha velocidad, porque el corazón de los nuevos sistemas (el API)
ya lo tienes desarrollado. En cualquier caso, gracias a REST y la
separación del código también tendrás menor mantenimiento.

Puede producirse en determinadas circunstancias mayor rigidez en

el desarrollo, sobre todo al ser dos proyectos independientes, tu
back basada en REST y el/los frontales, pueden surgir situaciones
de des-sincronización. Por ejemplo desde el cliente detectas que
necesitas nuevas cosas del API y los encargados de crearlas en la
parte del server pueden estar a otro ritmo y tardar en desarrollarlas.

Requiere más conocimientos, te obliga a salir de la zona de confort

a la que quizás estemos. Aparte de conocer tus lenguajes, bases de
datos, librerías, necesitarás aprender acerca del protocolo HTTP.

Conclusión
En definitiva observarás que las ventajas e inconvenientes del
desarrolla basado en API REST están muy interligados. Lo que
puede comenzar como una ventaja puede suponer una desventaja
en otro punto de tu aplicación. Sin embargo, como hemos dicho,
existen muchas situaciones en las que desarrollar basados en un
API nos puede aportar un gran adelanto.

Desarrollo de servicios WCF Restful con métodos GET y POST

Aquí verá cómo crear un servicio basado en WCF REST. En este ejemplo,
definiremos 2 métodos GetSampleMethod (el tipo de método es GET) y
PostSampleMethod (el tipo de método es POST).
• El método GET tomará la entrada como cadena y devuelve una
cadena formateada
• El método POST tomará una entrada como XML (registro de
usuario) y devolverá una cadena de estado
Nota: Uno debe tener conocimientos básicos de qué es WCF, por qué WCF
y mi artículo discutirá cómo usar WCF con webHttpBinding.
Definir el servicio WCF
1. Abra VS 2010 y seleccione un nuevo proyecto, luego seleccione WCF y
seleccione Aplicación de servicio WCF y asígnele el nombre WCF Rest
Based.
2. Ahora agregue una nueva clase de servicio a esta aplicación como
"MyService.svc".
3. Abra la interfaz IMservice.cs y agregue el siguiente código

o Contrato de operación: método posterior a la muestra

o Tipo de método WebInvoke = POST ya que estamos
implementando POST
o La plantilla URI define el formato de URL mediante el cual
se identifica/vincula este método. Nota: Nombre del
método, nombre de la plantilla URI y nombres del
contrato de operación pueden no ser los mismos medios,
pueden ser diferentes
o PostSampleMethod aceptará una cadena XML como
entrada en el método POST. Usando Stream como
parámetro de entrada podemos deserializar los datos de
entrada antes de usarlos

4. [OperationContract(Name = "PostSampleMethod")]
5. [WebInvoke(Method = "POST",
6. UriTemplate = "PostSampleMethod/New")]
7. string PostSampleMethod(Stream data);

• Nombre del contrato de operación: GetSampleMethod

• El tipo de método definido por el atributo WebGet es GET
• Es necesario incluir los siguientes espacios de nombres

1. using System.ServiceModel.Web;
2. using System.ServiceModel
3. using System.Runtime.Serialization
4. using System.IO
5. [OperationContract(Name = "GetSampleMethod")]
6. [WebGet(UriTemplate = "GetSampleMethod/inputStr/{name}"
)]
7. string GetSampleMethod(string name);

4. Abra la clase MyService.cs y proporcione la implementación de los métodos

definidos en la interfaz IMyService como se muestra a continuación
 1. publicstring PostSampleMethod(Stream data) {
2. // convert Stream Data to StreamReader
3. StreamReader reader = new StreamReader(data);
4.
5. // Read StreamReader data as string
6. string xmlString = reader.ReadToEnd();
7. string returnValue = xmlString;
8.
9. // return the XMLString data
10. return returnValue;
11. }
12. public string GetSampleMethod(string strUserName) {
13. StringBuilder strReturnValue = new StringBuilder();

14. // return username prefixed as shown below

15. strReturnValue.Append(string.Format("You have entere
d userName as {0}", strUserName));
16. return strReturnValue.ToString();
17. }

Definir la configuración para el servicio WCF

1. Abra web.config ya que necesitamos definir la configuración para
nuestro servicio WCF. Si desea que se acceda a nuestro servicio como
parte de webHttp, entonces debemos definir webHttpBinding y
mexHttpBinding.
2. En System.ServiceModel se define la configuración como se muestra a
continuación.

1. <services>
2. <servicename="WcfRestBased.MyService"
3. behaviorConfiguration="myServiceBehavior">
4. <endpointname="webHttpBinding"
5. address=""
6. binding="webHttpBinding"
7. contract="WcfRestBased.IMyService"
8. behaviorConfiguration="webHttp"
9. >
10. </endpoint>
11. <endpointname="mexHttpBinding"
12. address="mex"
13. binding="mexHttpBinding"
14. contract="IMetadataExchange"
15. />
16. </service>
17. </services>
 1. Nombre del servicio: para encontrar lo que se debe
proporcionar, luego haga clic derecho en el servicio y seleccione
la opción ViewMarkup. Por ejemplo, en mi caso es MyService.svc,
busque el atributo de servicio y use la cadena completa en mi
caso es Service="WcfRestBased.MyService
"behaviorConfiguration: puede ser cualquier nombre, pero se
usará nuevamente cuando definamos la configuración de
comportamiento. En mi caso, es myServiceBehavior

Endpoint para webHttpBinding.

Nombre del punto final: debe ser webHttpBinding si está

configurando para

una dirección de acceso web: podemos dejarlo

en enlace vacío: debería Ser

contrato webHttpBinding: debe ser

Namespace.Interfacename. En mi caso es
wcfRestBased.IMyService

comportamientoConfiguración: debería ser webHttp

EndPoint para mexHttpBinding

Estos valores deben ser los mismos que se muestran arriba

2. Ahora defina el comportamiento del Servicio como se muestra a
continuación en System.ServiceModel. El nombre
"myServiveBehavior" debe coincidir con el nombre de
configuración del comportamiento definido en la etiqueta de
servicio (que se muestra arriba)
3. <behaviors>
4. <serviceBehaviors>
5. <behavior name="myServiceBehavior" >
6. <serviceMetadata httpGetEnabled="true"/>
7. <serviceDebug includeExceptionDetailInFaults="fa
lse" />
8. </behavior>
9. <behavior>
10. <!– To avoid disclosing metadata informatio
n,
11. set the value below to false and rem
ove the metadata endpoint
12. above before deployment –>
13. <serviceMetadata httpGetEnabled="true"/>
14. <!– To receive exception details in faults
for debugging purposes,
15. set the value below to true. Set to
false before deployment
16. to avoid disclosing exception inform
ation –>
17. <serviceDebug includeExceptionDetailInFault
s="false"/>
18. </behavior>
19. </serviceBehaviors>
20. <endpointBehaviors>
21. <behavior name="webHttp">
22. <webHttp/>
23. </behavior>
24. </endpointBehaviors>
25. </behaviors>

Levantar el proyecto y realizar pruebas.