Java Web Services - REST Se pueden encontrar ejemplos en https://github.com/ldebello/javacuriosities/tree/master/JavaEE/JavaWebServices

1. Java Web Services
REST
Email de consultas: luisdebello.cursos@gmail.com

2. ¿Que es REST?
REpresentational State Transfer
Define un estilo de arquitectura para desarrollar aplicaciones web
distribuidas que se basa en el uso del protocolo HTTP e Hypermedia.
Principios:
 Stateless (No mantiene estado)
 Exponer URIs (Uniform Resource Identifier) con forma de directorios
 Uso de verbos HTTP
 Recursos
Java Web Services

3. Stateless (No mantiene estado)
Java Web Services

4. URIs (Uniform Resource Identifier)
Java Web Services
 URL: Uniform Resource Locator, o Localizador Uniforme de Recursos.
Son unas cadenas de texto que se usan para nombrar recursos en Internet
para su localización.
Ejemplo:
http://es.wikipedia.org:80/wiki/Special:Search?search=tren&go=Go
 URN: Uniform Resource Name, o Nombre Uniforme de Recursos. Son
unas cadenas de texto que se usan para nombrar recursos en Internet para
su identificación.
Ejemplo: urn:isbn:0451450523
 URI: Uniform Resource Identifier, o Identificador Uniforme de Recursos.

5. Exponer URI
Java Web Services
Las URIs deben ser intuitivas, hasta el punto de que sea fácil adivinarlas.
Pensemos en las URI como una interfaz auto-documentada que necesita
de muy poca o ninguna explicación o referencia para que un desarrollador
pueda comprender a lo que apunta, y a los recursos derivados
relacionados.
La raiz, /discusion, tiene un nodo /temas como hijo. Bajo este nodo hay un
conjunto de nombres de temas (como ser tecnología, actualidad, y más),
cada uno de los cuales apunta a un hilo de discusión. Dentro de esta
estructura, resulta fácil recuperar hilos de discusión al escribir algo
después de /temas/.

6. Verbos HTTP
Java Web Services
Request: GET/users
Response: 200 content-type: application/json
Request: GET/users/11
Response: 200 content-type: application/json
Request: POST/users
Response: 201 content-type:application/json
Request: PUT/11
Response: 200 content-type: application/json
Request : DELETE/11
Response: 204 no content

7. Recursos
Java Web Services
Algunos códigos típicos mas su descripción
 OK(200, "OK")
 CREATED(201, "Created")
 ACCEPTED(202, "Accepted")
 NO_CONTENT(204, "No Content")
 NOT_MODIFIED(304, "Not Modified"),
 NOT_FOUND(404, "Not Found")
 NOT_ACCEPTABLE(406, "Not Acceptable")
/users: Listado de usuarios
/users/{id}: Muestra un usuario

8. Múltiples representaciones
Java Web Services
 Content-Type: Nos dice que tipo de representación tiene los datos que
enviamos
 Accept: Le decimos la representación del dato esperado y luego a
esperar.

9. HTTPs Headers
Java Web Services
 Content-Type: Nos dice que tipo de representación tiene los datos que
enviamos.
 Accept: Le decimos la representación del dato esperado y luego a
esperar.
 ETag: Podemos controlar si el recurso ha sido modificado desde la ultima
vez que accedimos con un hash.
 If-None-Match: Se usa para validar su valor contra el Etag para ver si es
distinto y actualizarlo, If-Match hace lo inverno. Si no hay cambios el
servidor puede devolver una respuesta con estado HTTP 304 Not
Modified.
 Last-Modified/If-Modified-Since: Permite saber si el recurso se
modificado en base a la fecha del sistema

10. HATEOAS (Soportado por JAX-RS 2.0)
Java Web Services
HATEOAS (Hypermedia as the Engine of Application State), Es una
restricción de la arquitectura de la aplicación REST que lo distingue de la
mayoría de otras arquitecturas. El principio es que un cliente interactúa con
una aplicación de red completamente a través de hipermedia
proporcionadas dinámicamente por los servidores de aplicaciones. Es
como que el cliente REST debe ir navegando por la información y no
necesita ningún conocimiento previo acerca de la forma de interactuar con
cualquier aplicación o servidor más allá de una comprensión genérica de
hipermedia.
La restricción HATEOAS desacopla cliente y el servidor de una manera
que permite la funcionalidad del servidor para evolucionar de forma
independiente.

11. REST vs RESTful
Java Web Services
Dependiendo si cumplimos todos los niveles podemos decir que nuestra API
es RESTful. El RMM (Richardson Maturity Model) define 4 niveles [0-3],
donde cumplir con el nivel 3 es ser RESTful.

12. Level 0: Swamp of POX(Plain old XML)
Java Web Services
 La comunicación es sobre HTTP a un End Point. El cliente se comunica
tanto de ida como de vuelta al mismo End Point utilizando un verbo HTTP
(Ejemplo POST).
 Para cada request/mensaje (XML por ejemplo), el server retorna un
response/mensaje (XML por ejemplo).
 Ejemplos de este nivel son SOAP y XML-RPC.

13. Level 1: Resources
Java Web Services
 La comunicación es con recursos, el cliente se comunica usando HTTP
pero a diferentes recursos.
 Cada recursos es alcanzable por medio de su URI.
 En lugar de acceder a "http://educacionit.com.ar/articulos", podemos
acceder a "http://educacionit.com.ar/articulos/1" o
"http://educacionit.com.ar/articulos/2", igualmente en este nivel seguimos
usando un único verbo.

14. Level 2: HTTP Verbs
Java Web Services
 Este nivel se basa en utilizar cada verbo HTTP para un propósito
específicos.
 Además debemos focalizarnos en el response para que maneje los
response code de manera correcta.

15. Level 3 - Hypermedia Controls
Java Web Services
 La comunicación es con recursos usando los verbos HTTP y manejando
distintas representaciones de nuestros recursos.
 En este nivel nuestra API puede tener URIs dinámicas que no afectan al
cliente ya que deben ser retornadas en el response generado.