# HTTP Proxy without the necessity to do another call

**URL:** <https://forum.alumio.com/t/http-proxy-without-the-necessity-to-do-another-call/671>\
**Category:** Feature Requests\
**Created:** [July 12, 2023, 12:48pm UTC](https://forum.alumio.com/t/http-proxy-without-the-necessity-to-do-another-call/671 "2023-07-12T12:48:43Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![floris](https://forum.alumio.com/letter_avatar_proxy/v4/letter/f/a3d4f5/32.png) [@floris](https://forum.alumio.com/u/floris)\
**Post date:** [July 12, 2023, 12:48pm UTC](https://forum.alumio.com/t/http-proxy-without-the-necessity-to-do-another-call/671/1 "2023-07-12T12:48:43Z")

</div>

Hi Alumio,

The HTTP Proxy feature is not used very often, but when it is used it’s generally very important.

I understand where the feature came from originally, however, I often get use-cases that are slightly different. They all share the same feature however, they need a realtime response.

Two examples I had:

- Somebody needed a non-realtime feed for their Channable connection (not that large, maybe 50-100kb). I created a process that stores every product every 24-hours and then on-demand merges that storage into a single XML and returns that to the requester.
- I’m currently working with a system that requires ‘acceptance’ of an order. The ‘acceptance’ message is not static, but needs to contain the items sent. The ‘acceptance’ needs to be the real-time response to the request.

Both of these use-cases are made very difficult because Alumio _requires_ the HTTP-proxy to do a call. This almost forces me to use [httpbin.org](http://httpbin.org) - which is something I’d reaaaally like to avoid.

Would a setting on the HTTP-proxy that just says “No outgoing call” be possible?

---

<div class="post-metadata">

**Author:** ![Gugi](https://forum.alumio.com/user_avatar/forum.alumio.com/gugi/32/236_2.png) [@Gugi](https://forum.alumio.com/u/Gugi)\
**Post date:** [July 17, 2023, 2:54pm UTC](https://forum.alumio.com/t/http-proxy-without-the-necessity-to-do-another-call/671/2 "2023-07-17T14:54:05Z")

</div>

Hi @floris

Thank you very much for your feedback.

I can imagine that would be a great addition for your use-cases. Furthermore, posting sensitive data to public web services like [httpbin.org](http://httpbin.org) would not be a preferable way. Therefore, I would pass your request regarding “No outgoing call” on to the team for further discussion of the possibility.

As for a workaround, for example #1, I would use the Alumio’s storage API endpoint, which is [`GET /storage/entities/{identifier}`](https://apidocs.alumio.com/#tag/Storage/operation/getStorageEntities) to fetch the entities of the storage as the destination URL. Then fetch the contents and merge them as the HTTP proxy’s response.

Regarding example #2, I would create an entity transformer to handle the order “acceptance”. Then, I would use an existing Alumio’s API endpoint, such as the [`POST /transformers/execute`](https://apidocs.alumio.com/#tag/Transformer/operation/executeTransformer) as the destination URL to execute the created entity transformer.

The workarounds might not be so practical, but they would be a good idea to avoid calling [HTTPBin.org](http://HTTPBin.org) or other public web services.

---

<div class="post-metadata">

**Author:** ![floris](https://forum.alumio.com/letter_avatar_proxy/v4/letter/f/a3d4f5/32.png) [@floris](https://forum.alumio.com/u/floris)\
**Post date:** [July 20, 2023, 2:33pm UTC](https://forum.alumio.com/t/http-proxy-without-the-necessity-to-do-another-call/671/3 "2023-07-20T14:33:12Z")

</div>

Hi Gugi,

Thanks for the advice! I never considered calling the transformers with the separate call, but that would indeed fix the issue - because it’s basicly the same as executing the transformer within the HTTP proxy, it can simply be a middle step.

For most many use-cases that would atleast make it possible to build it in Alumio, though the ‘no outgoing call’ option (like the outgoing ‘no action publisher’) would still be preferable.

---

<div class="post-metadata">

**Author:** ![Gugi](https://forum.alumio.com/user_avatar/forum.alumio.com/gugi/32/236_2.png) [@Gugi](https://forum.alumio.com/u/Gugi)\
**Post date:** [August 3, 2023, 7:37am UTC](https://forum.alumio.com/t/http-proxy-without-the-necessity-to-do-another-call/671/4 "2023-08-03T07:37:09Z")

</div>

Hi Floris,

We are happy to help you with the suggestion.

We discussed the possibility of the “no outgoing call” and we don’t think that we will implement it in the future. We have an HTTP client plugin called “Mock requests” that would mock the request and returned the response defined in the plugin instead of actually calling the destination endpoint.

Another thing is, we have another issue, which the “Transformer response data” response processor can only access the origin request’s query (GET) parameters. We will have to research further about the possibilities to overcome this issue.

---

<div class="post-metadata">

**Author:** ![floris](https://forum.alumio.com/letter_avatar_proxy/v4/letter/f/a3d4f5/32.png) [@floris](https://forum.alumio.com/u/floris)\
**Post date:** [August 3, 2023, 7:58am UTC](https://forum.alumio.com/t/http-proxy-without-the-necessity-to-do-another-call/671/5 "2023-08-03T07:58:25Z")

</div>

Hi Gugi,

The ‘mock requests’ feature is a pretty good alternative to calling the transformer directly - keeping transparancy/logging while being only a minimal inconvenience.

I’ve not really used the ‘mock requests’ feature, so I don’t know: can you use JMESPath queries in the ‘mock requests’ body? Otherwise, you still can’t send (and receive back) dynamic data.

---

<div class="post-metadata">

**Author:** ![Gugi](https://forum.alumio.com/user_avatar/forum.alumio.com/gugi/32/236_2.png) [@Gugi](https://forum.alumio.com/u/Gugi)\
**Post date:** [August 22, 2023, 10:16am UTC](https://forum.alumio.com/t/http-proxy-without-the-necessity-to-do-another-call/671/6 "2023-08-22T10:16:40Z")

</div>

Hi Floris,

Unfortunately, the Mock request plugin doesn’t support placeholders yet. Therefore, we don’t think it can help you in this specific case.

As I mentioned in my previous reply, the feasible solution would be setting the destination endpoint to one of the Alumio API endpoints that is related to your flow. For example, getting a content of an Alumio storage or executing an entity transformer.
