2010-07-21 28 views
10

Soy nuevo en los servicios web RESTful. Estamos tomando la ruta REST para construir nuestros servicios web públicos para ser consumidos por nuestros clientes. Y tuve algunas preguntas.RESTful web services

¿Hay algún tipo de limitación con los servicios de web REST puros? y si es así, ¿un servicio web REST híbrido se haría cargo de esas limitaciones?

Estoy pensando en utilizar SSL + Hash Message Authentication Code (HMAC) en el encabezado de autorización para la seguridad junto con el filtrado basado en IP. ¿Qué piensan ustedes al respecto?

¿Hay alguna buena herramienta del lado del cliente para las pruebas? Actualmente estoy usando el siguiente http://code.google.com/p/rest-client/

¿Y qué tal algún tipo de herramienta de generación de código del lado del cliente?

Los siguientes enlaces son mi fuente de información.

http://msdn.microsoft.com/en-us/library/dd203052.aspx

http://blogs.msdn.com/b/endpoint/archive/2010/01/07/getting-started-with-wcf-webhttp-services-in-net-4.aspx

Respuesta

5

Este es un buen punto de inicio de un servicio web WCF REST:

REST/SOAP endpoints for a WCF service

(BTW: Stackoverflow tiene una especie agradable resto de las direcciones URL.) Puede probar un servicio REST con sólo un navegador web (Vaya a la url y obtenga el XML o JSON). Fiddler es también una buena herramienta, y FireBug-plugin para FireFox. Normalmente hago un proyecto de interfaz de servicio delgado y un proyecto de lógica separado (probado por unidad).

Para la autenticación, primero generaría un Guid y una marca de tiempo. Luego, basado en esos hash (.NET es compatible con SHA256 y SHA512). El Guid se puede almacenar en el servidor (tabla de la base de datos) para asignarle una identificación numérica concreta. A continuación, puede tener una URL resto como:

/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y 

y simplemente desactivar la comprobación de marca de tiempo de hash & en el entorno de desarrollo (por ejemplo, con AOP). Con la marca de tiempo verificaría que el sello esté entre 15 minutos atrás y adelante en el tiempo (= debería ser suficiente para evitar ataques).

¿Su servicio será visible para el público/Internet y es su cliente un cliente jQuery o Silverlight? Entonces todavía tiene un problema: no desea incluir una clave secreta en el código de software del cliente.

Así que debe generar hash en el servidor y algún tipo de cookie para almacenar la sesión del cliente. (Esto puede hacerse, por ejemplo, con una página/aplicación de inicio de sesión separada en una carpeta con diferentes archivos de configuración.) Recuerdo que this book tenía algo sobre el tema:

Si desea habilitar el HttpContext cuando usa WCF, necesita configurar <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> bajo <system.serviceModel>. Luego puede verificar la identidad del usuario actual desde HttpContext.Current.User.Identity.Name.

Sin embargo, si desea hacer un servicio REST puro, entonces no utiliza cookies, sino una Autenticación Básica HTTP junto con SSL/TLS para cada llamada.

Creo que es fácil hacer un cliente con solo LINQ2Xml o jQuery, por lo que tal vez no sea necesaria la generación del cliente.

O también puede tener ambas, una interfaz SOAP y REST, y usar una referencia de servicio para crear un cliente.

+0

¿por qué necesito el guid? –

+0

Una vieja pregunta es "¿Cuál es mejor ID: numérica o Guid?" Guid es más seguro ya que no puedes adivinarlo. Pero la identificación numérica es más clara, simple y limpia. Si generas un hash solo por identificador numérico y marca de tiempo, no es tan seguro: después de todo, se han roto todos los algoritmos de hash principales (MD5, SHA). Pueden generar sumas de comprobación simétricas válidas. No tan rápido que importaría ahora, pero tal vez en unos pocos años la situación sea diferente. Con esta solución obtienes ventajas de ambos tipos: No se pueden adivinar códigos hash válidos fácilmente, pero no es necesario transferir identificadores basados ​​en Guid. –

+0

:) mi pregunta no era "guid vs number". Era más como. cuándo y quién genera el guid en el flujo de trabajo? –

7

La primera cosa a tener en cuenta es que un servicio resto debe ser sin estado, que es muy diferente en comparación con un SOAP/RPC tipo de interfaz de servicio. El uso de la metodología REST requiere que reconsidere cómo desea que sus clientes interactúen con el servicio, desglosando las interacciones en llamadas a métodos claros y concisos.

REST
+ mensajes Ligero, muy poca sobrecarga (que no sean el propio XML)
+ resultados fácilmente legibles, puede probar fácilmente con un navegador web
+ Fácil de implementar
- Interfaz más flojo, el tipo flojo de cheques

de SOAP
+ más rígida, con una definición estricta contrato
+ un montón de herramientas de desarrollo disponibles.

Mirando a través de la documentación de WCF MSDN, el soporte WCF SOAP se integró desde el principio mientras que el soporte REST es una característica recientemente agregada. Yo mismo estoy teniendo dificultades para encontrar documentación de autenticación/seguridad para los servicios REST, ya que la mayoría de la documentación está dirigida a SOAP.

Herramientas de generación del lado del cliente: No he encontrado ninguna para los servicios REST, ya que REST no define un contrato de servicio como lo hace SOAP. WADL es un intento de hacer eso para los servicios REST. http://en.wikipedia.org/wiki/Web_Application_Description_Language http://wadl.codeplex.com/

Estoy interesado en leer más respuestas que tratan de autenticación y seguridad, ya que estoy investigando eso mismo.

+0

Una buena introducción a WCF y REST está aquí: http://msdn.microsoft.com/en-us/magazine/dd315413.aspx – schoetbi

0

Una cosa a tener en cuenta es que puedes tomar REST como filosofía (todo debe ser accesible mediante una URL limpia, sin cadenas ocultas) o como un dogma (tienes que usar PUT y ELIMINAR incluso si eso significa una gran cantidad de dificultades en la línea).

el énfasis está en la simplificación - como el uso de tipos de datos simples para params en lugar de pileups Stuctured, ni interfaz clobering por razones superfluas (como remolque gigante página "título" en un URL), no utilizar los encabezados que no son bien conocidas y estándar de facto.

Por lo tanto, puede diseñar una interfaz RESTful perfectamente con solo OBTENER y conservar la capacidad de uso y la capacidad de prueba de los navegadores web. También puede usar cualquier método de autenticación estándar o varios de ellos para la redundancia, dependiendo de su público objetivo real. Si está creando una aplicación para ejecutar en corpnet con credenciales y tokens estandarizados, puede seguir usándola. Si está haciendo algo para un acceso muy general, puede usar una combinación de argumentos y/o cookies GET: mantiene sus URL limpias para el 99,99% de los usuarios.

Incluso puede servir tanto JSON como XML (como los mapas de Google, por ejemplo) y seguir siendo RESTfull, pero no puede hacer SOAP a escala completa (tipos de entradas complejas, etc.). Puede hacer SOAP limitado: tipos simples para las solicitudes, siempre expresables como args GET, las personas aún obtienen WSDL para la documentación.

Espero que esto represente una imagen suficientemente flexible: la forma de pensar por encima de cualquier dogma estricto.