I'm still very unclear on a legitimate use case for this, and personally wouldn't do it until I had a good reason.

That said, a couple ideas on how to implement:

* Use an alternate domain, eg `insecure.domain.com`

* Use an alternate path prefix, eg `domain.com/insecure/` -- your app would have to be able to handle this

* Use a parameter that sets a cookie that your load balancer/reverse proxy can understand, eg, `http://domain.com/?https=false`, and will prevent redirect -- definitely the most complex from the proxy point-of-view, but means the URL (other than the scheme) is consistent for both types of user

I sometimes parse web data with uC based devices that are not capable of doing https with the memory space available. I appreciate the ability to use http when I need to.

I use http from embedded devices that cannot do https due to memory constraints. Http access is appreciated for this use case.

But.... Do you guys have a business model that is going to keep you around long enough for me to bother hardcoding your api into embedded devices? I build things that connect real world actions to cryptocurrency markets, diverting power, metering resource consumption, etc.

Please get in touch by email if you need something more than the free API.

For your embedded devices, we can make something special just for you