web-services - sirve - servicios rest java
¿Podemos hacer que el servicio web de Restful sea un estado (3)
El servicio web, ya sea en reposo o en SOAP, está diseñado de forma predeterminada sin estado. Pero puede haber casos de uso donde se requiere que sea un estado. El Marco de recursos de servicios web (WSRF, por sus siglas en inglés) proporcionado por OASIS, se puede utilizar para hacer que un servicio web SOAP sea un estado. Agregue un atributo ResourceProperties al punto final y agregue una operación ResourceProperty al WSDL y páselo a través de los servicios web.
El resto se involucra en la transferencia de estado y, para que sean de estado, podemos usar el estado de sesión persistente del lado del cliente o db, y transferirlos a través de invocaciones de servicios web como un atributo en el encabezado o un parámetro del método.
He estado leyendo sobre los servicios web Restful que son apátridas. También puedo ver que la mayoría de los servicios web basados en Soap también son sin estado y pueden tener estado si es necesario y hacerlos dependientes de la implementación. Por lo tanto, si un servicio web basado en jabón es de estado, entonces se pasará un ID de sesión con cada solicitud, para continuar con la sesión.
Mi consulta es por qué no se puede hacer lo mismo con los servicios web Restful, creo que debería poder implementar un servicio web que pueda continuar con la misma sesión en la que el Id. De sesión se pasa con Restful webservice.
Entonces, mi pregunta es: ¿Son los servicios web RestFul solo un concepto con una pauta para no hacerlos constantes? ¿O habrá controles en las bibliotecas de servicios web Restful [como Jersey] para evitar que las personas lo hagan?
La apatridia de REST está diseñada para garantizar que las aplicaciones se amplíen bien. Puede agregar estado, pero está en una compensación en escalabilidad.
Una de las razones más comunes para agregar estado a REST es la autenticación. Una vez que se establece una conexión segura, se puede enviar una cookie segura al cliente. Esta cookie es agregada por el cliente a todas las solicitudes para la sesión. El servidor mantiene el estado y luego carga ese estado con cada solicitud basada en la cookie.
Considere una página web simple. Si no está manteniendo el estado, puede colocar un proxy inverso, almacenar en caché la página en la memoria por URL y distribuir ese recurso en muchos servidores para cargar. Si ahora agrega el nombre del usuario que ha iniciado sesión actualmente a esa página web, ya no puede almacenar en caché nada (al menos en el nivel HTTP más básico). La respuesta ahora solo se puede almacenar en caché con una combinación de la cookie de autenticación y la URL.
Por lo que sé, nosotros (los desarrolladores de .net) podemos usar el enlace WS en wcf para servicios web con estado.