.net - studio - Comenzando con REST
web service rest json c# (6)
Cuando comencé a desarrollar servicios web REST, leí REST API Design Rulebook de Mark Masse. Una vez que conozca los conceptos básicos y la teoría, podrá implementar REST con WCF, HTTPListener o ServiceStack. Todos estos frameworks son .NET y están bastante bien documentados ...
Te recomendaría stack de servicio (http://www.servicestack.net/) hay suficiente información en la web para comenzar.
WCF ofrece la API web ASP.NET, está bien, pero no la uso.
En cualquier caso, hoy no existe un buen marco REST, debe elegir uno que le resulte fácil de usar y luego aplicar la teoría que aprendió del libro.
Estoy buscando buenos enlaces con las mejores prácticas y ejemplos de código para crear servicios web REST completos usando .NET.
Además, cualquier otra información que pueda tener con respecto a REST sería muy apreciada.
La mejor introducción que he leído es el libro RESTful Web Services , que va más allá de explicar el modelo y los principios y, de hecho, le muestra cómo diseñar un servicio web RESTful. Lo más útil es su lista de verificación sobre cómo escribir / especificar una API REST:
- Calcule el conjunto de datos [es decir, especifique el modelo de datos].
- Divida el conjunto de datos en recursos. Para cada tipo de recurso:
- Nombra los recursos con URI.
- Exponga un subconjunto de la interfaz uniforme [es decir, especifique qué métodos HTTP se usan y qué hacen].
- Diseñe las representaciones aceptadas del cliente [por ejemplo, el formato XML que puede PONER o PUBLICAR].
- Diseñe las representaciones que se le brindan al cliente [por ejemplo, el XML que recibe].
- Integre este recurso en los recursos existentes, utilizando enlaces y formularios de hipermedia.
- Considere el curso típico de eventos: ¿qué se supone que sucederá? [Esto es como un escenario de éxito principal de caso de uso.]
- Considera las condiciones de error. [Esto es como casos de excepción de caso de uso.]
Los artículos de la serie " RESTful Web " en xml.com son una excelente introducción.
El autor (Joe Gregorio, de la fama del Protocolo de publicación Atom) también publica periódicamente artículos interesantes sobre todo lo que REST en su weblog . " RESTify DayTrader " (la arquitectura REST aplicada a una aplicación de negociación bursátil de referencia) es un buen punto de partida. También me gusta " ¿Por qué tantos frameworks web de Python? ", Que muestra la implementación de un pequeño marco web relajante en Python.
Windows Communication Foundation es compatible con el modelo REST desde .NET 3.5 .
Puede encontrar documentación y ejemplos de código en MSDN:
Algunos recursos para aprender REST:
- Documentación REST en xFront.com
- Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red. Capítulo 5: Representational State Transfer (REST) (Disertación de doctorado de Roy Fielding - autor de REST)
- REST
ADO.Net Data Servcies hace que sea muy fácil construir y consume servicios web RESTful en el mundo .Net, pero, no obstante, es importante comprender los conceptos. Comparado con WCF (que agregó soporte REST más adelante), ADO.Net Data Services se construyó principalmente para REST.
Las pautas para construir servicios web RESTful tienen toda la información sobre los recursos que necesita.
Esta es otra entrada de blog útil:
Las restricciones de interfaz uniformes describen cómo un servicio creado para la Web puede ser un buen participante en la arquitectura web. Estas restricciones se describen brevemente de la siguiente manera:
1) Identificación de los recursos: Un recurso es cualquier elemento de información que puede ser nombrado y representado (por ejemplo, un documento, un precio de las acciones en un punto determinado en el tiempo, el clima actual en Las Vegas, etc.). Los recursos en su servicio se deben identificar usando URI.
2) Manipulación de recursos a través de representaciones: una representación es la representación física de un recurso y debe corresponder a un tipo de medio válido. El uso de tipos de medios estándar como los formatos de datos detrás de su servicio aumenta el alcance de su servicio haciéndolo accesible a una amplia gama de clientes potenciales. La interacción con el recurso debe basarse en la recuperación y manipulación de la representación del recurso identificado por su URI.
3) Mensajes autodescriptivos: Siguiendo los principios de apatridia en las interacciones de su servicio, el uso de tipos de medios estándar e indicando correctamente la capacidad de caché de los mensajes a través del uso del método HTTP y los encabezados de control garantiza que los mensajes sean autodescriptivos. Los mensajes autodescriptivos permiten que los mensajes sean procesados por los intermediarios entre el cliente y el servidor sin afectar a ninguno de los dos.
4) Hipermedia como motor del estado de la aplicación: el estado de la aplicación debe expresarse mediante URI e hipervínculos para la transición entre estados. Esta es probablemente la más controvertida y menos entendida de las limitaciones arquitectónicas establecidas en la disertación de Roy Fielding . De hecho, la disertación de Fielding contiene un argumento explícito contra el uso de cookies HTTP para representar el estado de la aplicación y hacer que este punto sea más común, aunque a menudo se ignora.