Cambiando el método HTTP de la petición al llamar al target endpoint

Es posible que al definir nuestra API REST requiramos que un endpoint tenga un método HTTP para la petición que no se corresponda con el de la llamada al servicio que vayamos a hacer posteriormente. Por ejemplo, podemos requerir que nuestro endpoint necesite llamarse mediante un PUT con un objeto JSON como payload pues vamos a modificar el valor de algún atributo en el lado del servicio sin afectar al resto, pero para llamar al servicio necesitemos hacer un POST al tratarse de un servicio SOAP.

En estos casos al definir nuestro flujo dentro de Apigee, ¿cómo mantendremos una coherencia para que no se pierda el flujo? Una posible solución podría ser no incluir el verbo en la condición del flujo para permitir que a la vuelta, una vez hayamos cambiado el método HTTP de la petición, vuelva por el mismo camino.

Esto no es una buena práctica pues permitiríamos que el flujo se ejecutara para cualquier método HTTP que llamara al  path definido para el endpoint obteniendo comportamientos no deseados. En el ejemplo anterior, por ejemplo, podría entrar en el endpoint tanto un "crear usuario" (POST) como el método "establecer valor de un campo" (PUT), que es el endpoint que se ha definido realmente.

Solución propuesta

Antes de pasar a detallar la solución, indicar que ésta se basa en la experiencia con la plataforma y no atiende a posibles recomendaciones que pueda haber en la documentación por lo que no podemos asegurar que sea una solución óptima y aplicable en todos los casos.

La solución propuesta cosiste en incluir el método HTTP de nuestro endpoint, tal como se ha definido en la API REST, como condición del flujo del endpoint junto al path definido para él y llevarnos el tratamiento de la respuesta del servicio al target endpoint.

Para ello, mediante una política de Asignación de mensajes, se establece un valor único para este endpoint que será evaluado en la condición de flujo del target endpoint. En el siguiente ejemplo se ilustra la asignación de la variable con el valor comentado en la propia política que establece el mensaje y petición HTTP del servicio. 

De esta forma identificaremos de forma unívoca el endpoint y se ejecutarán las políticas necesarias para el tratamiento de la respuesta sin necesidad de volver en el flujo satisfaciendo la condición de entrada.

Debemos insistir en que sólo podremos aplicar esta solución si no tenemos ninguna política a ejecutar en la respuesta del flujo de vuelta del proxy endpoint y si podemos transladar la evaluación de la respuesta a la respuesta del target endpoint en todo caso.