Templar: A proxy to improve HTTP API interactions
1–10 of 26 posts
Re: Templar: A proxy to improve HTTP API interactions
#2Based on the first sentence of the description, I was expecting a proxy that added callback support to arbitrary APIs. I hit "https://my-templar-proxy/?real_url=$x&real_param_a=10&callba..., it hits the real API and waits for the response, then hits my callback with it.
I feel like that might be more useful than what appears to be just a special-purpose varnish/squid
Re: Templar: A proxy to improve HTTP API interactions
#3Based on the first sentence of the description, I was expecting a proxy that added callback support to arbitrary APIs. I hit " https://my-templar-proxy/?real_url=$x&real_param_a=10&callba... , it hits the real API and waits for the response, then hits my callback with it. I feel like that might be more useful than what appears to be just a special-purpose varnish/squid
Author here! That's certainly an interesting feature that could be added. I have on the future list to support sending responses back via AMQP. Your callback scheme isn't much different than that.
Re: Templar: A proxy to improve HTTP API interactions
#4This could be really useful for sending outbound webhooks, if it grew a couple of extra features:
1. "Fire and forget" ability. It would be great if I could send a request through Templar with an X-Templar-Fire-And-Forget: 1 HTTP header which means "deliver the request in your own time, but return a 200 OK to my client straight away so I don't have to wait for it.
2. It would be great if it could "validate" the URLs going through it somehow. When sending webhooks, it's important to be sure that they are going to the rest of the internet and not being used to probe internal IPs/hostnames of your own infrastructure. This is a bit of a fiddly problem, which is why it would be nice to have a proxy like Templar take it on. Take a look at the blocked_hosts section in http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib... for an example. I'm not sure how this would translate into X-Templar HTTP headers though.
Re: Templar: A proxy to improve HTTP API interactions
#5This could be really useful for sending outbound webhooks, if it grew a couple of extra features: 1. "Fire and forget" ability. It would be great if I could send a request through Templar with an X-Templar-Fire-And-Forget: 1 HTTP header which means "deliver the request in your own time, but return a 200 OK to my client straight away so I don't have to wait for it. 2. It would be great if it could "validate" the URLs…
Fire-and-Forget is on the todo list. Since you're asking about it I'll bump it up. The later, Templar could have an option that tell it to only connect to public ips. Would that do it for ya?
Re: Templar: A proxy to improve HTTP API interactions
#6Based on the first sentence of the description, I was expecting a proxy that added callback support to arbitrary APIs. I hit " https://my-templar-proxy/?real_url=$x&real_param_a=10&callba... , it hits the real API and waits for the response, then hits my callback with it. I feel like that might be more useful than what appears to be just a special-purpose varnish/squid
Author here! That's certainly an interesting feature that could be added. I have on the future list to support sending responses back via AMQP. Your callback scheme isn't much different than that.
Congrats on the announcement. Templar looks like a great project.
Re AMQP, I want to mention that our Zurl project does something similar, but with ZeroMQ. It leads to some interesting possibilities: http://blog.fanout.io/2014/02/18/fun-with-zurl-the-http-webs...
Zurl is not an HTTP proxy though, but a ZeroMQ gateway. Templar with async responses would be much more generally useful to HTTP developers.
Re: Templar: A proxy to improve HTTP API interactions
#7Maybe I'm missing the point here, but I'm not entirely sure I see the point here.
What can Templar do for me that, say, nginx can't? All else equal, if nginx is already in my stack and Templar is not, why do I want to adopt Templar, or indeed even look twice at it?
Re: Templar: A proxy to improve HTTP API interactions
#8Earlier quoted context omitted.
Author here! That's certainly an interesting feature that could be added. I have on the future list to support sending responses back via AMQP. Your callback scheme isn't much different than that.
Congrats on the announcement. Templar looks like a great project. Re AMQP, I want to mention that our Zurl project does something similar, but with ZeroMQ. It leads to some interesting possibilities: http://blog.fanout.io/2014/02/18/fun-with-zurl-the-http-webs... Zurl is not an HTTP proxy though, but a ZeroMQ gateway. Templar with async responses would be much more generally useful to HTTP developers.
I agree, async responses are a great tool. It's a question of figuring out a good way of delivering them back to the client. Another option is a long poll endpoint within Templar that it can deliver a stream of responses on. AMQP is an easy option because it keeps Templar simple.
Re: Templar: A proxy to improve HTTP API interactions
#9Maybe I'm missing the point here, but I'm not entirely sure I see the point here. What can Templar do for me that, say, nginx can't? All else equal, if nginx is already in my stack and Templar is not, why do I want to adopt Templar, or indeed even look twice at it?
A great question. Nginx is not typically configured as a normal proxy but it can certainly do it. A difference is that Templar gives you control of options applied to each request differently rather than the same the same to all.
From timeouts to caching, one Templar can be used for all different kinds of upstream APIs.
Re: Templar: A proxy to improve HTTP API interactions
#10This could be really useful for sending outbound webhooks, if it grew a couple of extra features: 1. "Fire and forget" ability. It would be great if I could send a request through Templar with an X-Templar-Fire-And-Forget: 1 HTTP header which means "deliver the request in your own time, but return a 200 OK to my client straight away so I don't have to wait for it. 2. It would be great if it could "validate" the URLs…
Fire-and-Forget is on the todo list. Since you're asking about it I'll bump it up. The later, Templar could have an option that tell it to only connect to public ips. Would that do it for ya?
Yes, that would be excellent - do you mean just public IP ranges?
One possible snag: I heard from a co-worker that if you are running on EC2 and you make an HTTP request to another site that coincidentally is also hosted on EC2 that traffic can sometimes be routed over a private IP range.