Enlace local de REST
El enlace local mejora el rendimiento de la infraestructura de REST al proporcionar un flujo de REST optimizado.
Impide las peticiones REST HTTP de bucle de retorno cuando el WAR HCL Commerce está en el mismo servidor de aplicaciones y pasa directamente la correlación de datos de respuesta a la etiqueta de REST. Es decir, fuerza el comportamiento de la petición REST HTTP para que opere en una hebra única y evitar la necesidad de crear varias hebras para resolver las solicitudes subsiguientes. El enlace local impide las llamadas locales desde el servicio HCL Commerce a la capa de servicio REST e impide que se requieran recursos adicionales del servicio HCL Commerce (contenedor web).El enlace local opera en RESTtag. Soporta solicitudes bajo la implementación de RESTTag (wcf:rest).
- El enlace local de REST crea una solicitud de servlet interna que envuelve la solicitud original y una respuesta de servlet interna. La solicitud interna altera temporalmente el URL con el URL de REST iniciado desde el comienzo. Los parámetros, cabeceras y atributos se pasan de la solicitud original. Los atributos adicionales para la solicitud incluyen el distintivo para indicar si la solicitud actual está en el enlace local, la correlación de datos de respuesta y la correlación del cuerpo de la solicitud. Además, las constantes para el enlace local también se definen para la vista previa de la tienda.
- La respuesta interna altera temporalmente la cabecera y la secuencia de salida de respuesta para evitar cualquier sobrecarga adicional. Se crea una corriente de salida de enlace local aparte para la respuesta a fin de evitar que se sobrescriba la secuencia de salida de la solicitud original.
- Para las solicitudes que contienen un cuerpo (solicitudes POST y PUT), el cuerpo se añade como un atributo a la petición, en forma de correlación y se pasa a los manejadores. Cuando el cuerpo de la solicitud está vacío, el atributo de cuerpo de solicitud en la solicitud también está vacío. Cuando se añade la correlación de entrada de solicitud al atributo de la solicitud interna y se recupera cuando es necesario, se evita la serialización y la deserialización del cuerpo de la solicitud, con los datos en bruto utilizados cuando sea necesario. Toda la lógica para captar la correlación del cuerpo de la solicitud se realiza dentro del método com.ibm.commerce.foundation.rest.resourcehandler.AbstractResourceHandler.getMapFromRequest(HttpServletRequest request, String responseFormat). A continuación, el método devuelve un objeto JSONObject de la correlación de datos del atributo de la solicitud interna, cuando el distintivo IN_LOCAL_BINDING se establece en el atributo de la solicitud interna. Esta correlación de datos es una correlación hash que se compone de los datos de respuesta de la petición REST realizada.
- Se utiliza un asignador de peticiones para iniciar directamente una llamada REST sin una solicitud HTTP. El asignador se crea mediante el contexto de REST para la petición, y el URL de destino es la vía de acceso del URL de REST inicial. Después de recuperar un asignador, se realiza una include en él mediante los objetos de envoltura de respuesta interna y solicitud interna. Una vez que se ha creado y el contenedor de Servlets está activado, el servlet que está correlacionado con el URL de REST se entra en la creación del asignador. JSON es el formato de respuesta forzada para el enlace local y la correlación de datos de respuesta se establece como un atributo de la solicitud interna y, a continuación, se devuelve a la etiqueta REST. Al pasar directamente la correlación de datos, se puede omitir cualquier serialización o deserialización de los datos, en lugar de utilizar la correlación de datos sin procesar cuando sea necesario.
Optimizaciones de peticiones internas
Se crea una solicitud interna y una respuesta con una combinación de valores proporcionados por el archivo de configuración inicial y alteraciones de los valores originales. El formato de respuesta se establece en JSON (tanto el parámetro de consulta de solicitud como la cabecera establecen responseFormat como JSON). La lógica de respuesta se realiza en el proveedor de entidad JSON. El asignador se ejecuta en el URL de REST formulado mediante el contexto de REST que se creó en primer lugar al iniciar el servidor.
- Se omite la validación de sesión de usuario para reutilizar la señal de validación existente con el atributo de petición que indica el enlace local.
- Se omite el análisis de userId para captar el userId de la sesión de usuario existente.
- La cookie de autenticación, la cookie de sesión persistente y la sesión de usuario se recuperan del contexto de sesión.
- La correlación de entrada de solicitud se capta directamente desde el atributo de la solicitud interna y se evita la deserialización del cuerpo de la solicitud.
- Se omite cualquier invocación de XMLEntityProvider, ya que el enlace local funciona únicamente dentro de JSONEntityProvider.
- La etiqueta REST puede aceptar la correlación de respuesta como un atributo de la petición interna. Después de que el control se devuelva al RestTag y se omita el análisis de la corriente de salida.
Para la vista previa de la tienda, las vías de acceso de código similares al código proporcionado en RestPreviewServlet se reproducen en el tiempo de ejecución del asignador, con alteraciones para el enlace local. La vista previa de la tienda viene determinada por el distintivo in_Preview establecido en el atributo de la solicitud. El asignador de previsualización se crea mediante el contexto de servlet REST de la ServerConfiguration, y el URL objetivo es la ruta del URL inicial de REST. Después de recuperar un asignador, se realiza una include en él con los objetos de contenedor de respuesta interna y solicitud interna creados.
La correlación de datos resultante se pasa al proveedor de entidades JSON, se convierte en un objeto JSON y se añade como un atributo a la petición interna. Cualquier escritura o manejo de la corriente de salida de respuesta utiliza la corriente de salida de respuesta de enlace local para evitar escrituras innecesarias, ya que todos los datos se pasan a través de los atributos de petición. La etiqueta REST recupera la correlación de los atributos de petición.