¿Cuál es la forma correcta de hacer REST?

36

Todos hoy en día hacen SOA , incluso si algunos realmente no entienden de qué se trata. Entonces lo hacen mal. Usando eso como analogía, sé lo que es REST (o al menos creo que lo hago) y quiero hacer algo de eso. Pero quiero hacerlo bien.

Entonces mi pregunta es ¿cuál es la forma correcta de hacer REST?

JohnDoDo
fuente
1
Desbordamiento de pila 'descanso' etiqueta wiki parece estar tan cerca como se pone a recursos canónica en el contexto de la red pila Cambio
mosquito
17
Solo cerré los ojos por un tiempo ... tal vez voy a dar un paseo en bicicleta y luego me acuesto.
Edward Strange
¿REST no es básicamente solo usar una URL como mydomain.com/accounts y un verbo HTTP para invocar una operación? ¿Dónde el verbo indica si desea obtener, crear, actualizar o eliminar datos? Cuando pienso en REST, eso es lo que pienso.
The Muffin Man
2
@Nick, esa es la interpretación más común, la 'cosa real' es mucho más difícil de asimilar, y (por lo que puedo decir) es mucho más difícil de encontrar implementada en cualquier lugar ... (ver la respuesta de Wilk)
Benjol
3
@Nick, tu comprensión no es REST, es RPC sobre HTTP .

Respuestas:

30

Bueno, hay muchas maneras de aprender cómo construir una aplicación web RESTful y no, no hay una forma correcta única. RESTful no es un estándar, pero utiliza un conjunto de estándares (HTTP, URI, Mime Type, ...).

Comience con esto: cómo le expliqué REST a mi esposa

Luego, proceda con esto: RESTful Web Services Cookbook

Y luego haga todo su esfuerzo para desarrollar aplicaciones web porque la mejor manera de aprender es haciendo experimentos y puede aprender mucho de sus errores;)

No se preocupe si sus primeras aplicaciones web no serán completamente RESTful: ¡encontrará la manera de hacerlo!

Entonces, citando a Obi-Wan Kenobi, "¡que la fuerza te acompañe!" ;)

EDITAR

Ok, déjame ser más específico. ¿Quieres hacer una aplicación web RESTful, eh? Bueno, como dije, hay muchas maneras de hacerlo, pero esta es la guía principal.

Definición

REST (Representational State Transfer) es un estilo de arquitectura de software para sistema distribuido (como WWW). No es un estándar, pero utiliza un conjunto de estándares: HTTP, AJAX, HTML, URI, Mime Type, etc. Estamos hablando de la representación de un recurso, no de un recurso en sí mismo. Tomado de 'Cómo le expliqué REST a mi esposa':

Esposa : ¿ Una página web es un recurso?

Ryan : algo así . Una página web es una representación de un recurso. Los recursos son solo conceptos.

Restricciones de la arquitectura

  • Cliente-Servidor : el cliente y el servidor están separados por la Interfaz Uniforme (que se describe a continuación).
  • Sin estado : la comunicación servidor-cliente se realiza sin guardar un estado de cliente particular en el servidor.
  • Cachable : el cliente puede tener un caché de respuestas de solicitudes ya realizadas.
  • Sistema en capas : el cliente no sabe si está conectado directamente con un servidor final o si la comunicación se realiza a través de intermediarios.

Interfaz uniforme

  • Identificación de recursos: cada recurso debe ser identificado por un URI.
  • Protocolo : para poder comunicarse con el cliente y el servidor, se debe hacer un protocolo antes. Cada solicitud puede tener el tipo MIME correcto (aplicación / xml, texto / html, aplicación / rdf + xml, etc.), los encabezados correctos y el método HTTP correcto (consulte la descripción CRUD a continuación).

CRUDO

Ok, vimos que para identificar recursos podemos usar URI, pero necesitamos algo más para las acciones (agregar, modificar, eliminar, etc.): una gran bienvenida a CRUD (Crear, Leer, Actualizar y Eliminar).

  • Crear { HTTP: POST } { SQL: INSERT } => crear un nuevo recurso
  • Lea { HTTP: GET } { SQL: SELECT } => obtenga un recurso
  • Actualizar { HTTP: PUT } { SQL: UPDATE } => modificar un recurso
  • Eliminar { HTTP: DELETE } { SQL: DELETE } => eliminar un recurso

Ahora, con respecto a PUT y DELETE, podrían aparecer algunos problemas tecnológicos (los obtendrá con el formulario HTML): a menudo los desarrolladores evitan este problema usando POST para cada solicitud 'PUT' y 'DELETE'. Oficialmente, debes usar PUT y DELETE. Por cierto, haz lo que quieras. Mi experiencia me empuja a usar POST y GET cada vez.

--- La siguiente parte debe usarse pero no es un vínculo de REST: se trata de datos vinculados ---

URI

Resumen URI de detalles técnicos! Diga adiós a URI de la siguiente manera:

http://www.example.com/index.php?query=search&id=9823&date=08272012

¡Re-diseñe URI! Tome el enlace de arriba y cámbielo de la siguiente manera:

http://www.example.com/search/2012/08/27/9823

Eso está mucho mejor, ¿eh? Se podría hacer por:

Otra cosa: use diferentes URI para representar diferentes recursos:

Presta atención : ¡about.html y about.rdf no son archivos! ¡Podrían ser el resultado de una transformación XSLT!

Negociación de contenido

Si has llegado a este punto, ¡felicidades! Probablemente, esté listo para obtener conceptos más abstractos porque estamos ingresando en los detalles técnicos de la Web Semántica;) Bueno, cuando su cliente quiere un recurso, generalmente realiza la siguiente solicitud:

GET http://www.example.com/about
Accept: application/rdf+xml

Pero el servidor no responderá con about.rdf porque tiene un URI diferente ( http://www.example.com/about.rdf ). Entonces, ¡echemos un vistazo al patrón 303 ! El servidor devolverá esto:

303 See Other
Location: http://www.example.com/about.rdf

Y el cliente seguirá el enlace devuelto de la siguiente manera:

GET http://www.example.com/about.rdf
Accept: application/rdf+xml

Finalmente, el servidor devolverá el recurso solicitado:

200 OK
about.rdf

No se preocupe: ¡su aplicación cliente no hará nada de esto! El patrón 303 debe ser realizado por la aplicación del servidor y su navegador hará el resto;)

Conclusión

A menudo la teoría está muy, muy lejos de la práctica. Sí, ahora sabes cómo diseñar y desarrollar una aplicación RESTful, pero la guía anterior es solo una pista. Encontrará su mejor manera de construir aplicaciones web y probablemente no será lo que la teoría quiere. No te importe: D!

Bibliografía

Servicios web RESTful, Sameer Tyagi

Las API REST deben ser impulsadas por hipertexto, Roy Thomas Fielding

Servicios web RESTful: Lo básico, Alex Rodríguez

Flujo de trabajo REST de Webber

Wilk
fuente
1
Puede considerar agregar este enlace , que es la guía más completa que he encontrado.
Benjol
He visto PUT y POST utilizados con sus significados intercambiados (en relación con su respuesta): POST -> crear, PUT -> actualizar. ¿Alguna idea de qué significado se usa más ampliamente?
Andres F.
@Andres F .: jcalcote.wordpress.com/2008/10/16/… dice: Create = PUT si está enviando el contenido completo del recurso (URL) especificado. Crear = POST si está enviando un comando al servidor para crear un subordinado del recurso especificado, utilizando algún algoritmo del lado del servidor. Actualizar = PUT si está actualizando el contenido completo del recurso especificado. Actualización = POST si está solicitando al servidor que actualice uno o más subordinados del recurso especificado.
Wilk
@Benjol: voy a editar con su sugerencia;) ¡Gracias!
Wilk
1
@Wilk ¡Algunas cosas a tener en cuenta! Probablemente por qué nadie entiende esto correctamente: P
Andres F.
5

un libro bíblico REST o algo así ...

No es necesario un libro bíblico; Tenía las mismas preguntas exactas y aprendí todo lo que necesitaba o quería saber sobre REST leyendo estos tres artículos:

  1. Introducción para principiantes a HTTP y REST de Net Tuts +
  2. Servicios web RESTful: los fundamentos de IBM developerWorks
  3. RESTful HTTP en la práctica de InfoQ

Pero quiero hacerlo bien.

Como leerá en los artículos anteriores, la clave es pensar en las piezas accesibles de su aplicación como "recursos" que se pueden crear, recuperar, actualizar o eliminar utilizando los "verbos" HTTP existentes: OBTENER, PONER, PUBLICAR , BORRAR.

Además, sepa la diferencia entre PUT y POST , y cuándo usarlos. GET, PUT Y DELETE deben ser transacciones idempotentes, POST no.

Además, haga un uso adecuado de los códigos de estado HTTP cuando se comunique con el cliente.

CFL_Jeff
fuente