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