Today (June 19) Apilio only accepts GET requests from IFTTT and other services. Certain customers would appreciate the ability to send POST requests to Apilio.
A word on the HTTP method: Yes, currently you have to use GET. I know that this is not quite correct from a purist RESTful interpretation - actually, it should be implemented as PATCH method (https://tools.ietf.org/html/rfc5789). I chose GET to simplify the setup process for non-technical users (because GET might sound familiar to most).
In my opinion this is a very interesting request!!
But i think that the more important reason is the security… With the GET resquest, any person in the middle of the communication can see the request and can execute it later…
I think only accept GET resquest is a big security problem…
If apilio accepts POST request, the key can pass in the body and over a HTTPS connection the data can’t be view for a middle person.
I understand that the GET option is available to facilitate configuration, but I believe that the POST option should be given to ensure a minimum of security.
Thanks for your excellent work with apilio!!
Hi @Lobe,
we were able to integrate directly with IFTTT in the meantime and we are therefore encouraging users to migrate to that way of integrating.
We are trialing a more strict REST API that does not allow data updates via GET - you can check it out here: Apilio web API v1
But generally speaking, sending data via GET request is not as risky as many believe. Apart from the hostname, the URI and all data is in fact encrypted. A nice explanation is here: https://https.cio.gov/faq/#what-information-does-https-not-protect or of course directly at the source: https://www.ietf.org/rfc/rfc4366.txt
The problem is that all the data at the moment of the suggestion (I don’t know how works now with the ifttt integration) navigated on the url… Any person in the middle can reproduce the request and turn on the light…
But I don’t think that differentiates GET from POST requests.
The topic of replaying requests is not trivial and there is an interesting article on Cloudflare’s blog that also touches on it: https://blog.cloudflare.com/introducing-0-rtt/
If you send a post request over https, the identifier of the user and the identifier of the var can send in the body of the request. This data isn’t visible for any person in the middle. The most important data is the user identifier.
But that’s the same for a GET request. The path is not visible and any parameters are encrypted.
I am just loving this ahem discussion chain!
Is not the same…
Get request example:
https://www.url.com/service/asdfasdfdsfsfgdg/MyVar
Post request example:
https://www.url.com/service
Body params:
asdfasdfdsfsfgdg
Myvar
In the first request (GET), the URL is completely visible so the parameters are visible and anyone in the middle, copying the URL into the browser can relaunch the request.
In the second (POST), if the request is about HTTPS, the url is visible but does not provide compromised information. The body of the petition will not be visible, so no one can reproduce the petition.
I’m sorry for my English, I didn’t expect to have to write so much … hehehe
what a shame I can only do one “thumbs up”…
@Lobe I think that means we won! 
Came here wondering whether it’s possible to update/retrieve stored Variables (Boolean, Numeric, String) using GET requests, instead of having to route through IFTTT.
Reading thread, I think I’m still not sure about that particular tidbit.
Can someone clarify for this wayward n00b?? Thx!
We have a beta version of the REST API out with limited functionality to gather feedback and to see if there is demand for such a feature. The documentation is here: https://documenter.getpostman.com/view/7602053/S1TSZeSA
The docs and sample code are nice, but don’t show users how to SET a variable using GET or POST. I’m hoping the entire mechanism can coexist with IFTTT-based methods, while still providing direct HTTPS access if users prefer.
Want frosting for this cake? Allow users to view and edit all their variables on a single Web page, since sometimes it’s helpful to have a backend “control panel”. Helps debug your workflow faster than poking around one-by-one with URL calls to see what’s what.
Great feedback, thanks!
It currently supports only the one GET method documented, but we consider to expand depending on the user feedback. Thanks for your vote!
We are also working on improving the UI and adding new features, so stay tuned 
Philipp
I would like to execute Logicblocks directly from Siri via Shortcuts. Right now I trigger IFTTT from Siri through a web hook (via a Siti shortcut that GETs the URL), and that IFTTT applet triggers an Apilio logicblock, but passing through IFTTT introduces a delay.
We will have some great news to share soon on this topic - just wait for a couple of days 
I’m counting the days…
For everyone following this thread: This announcement is probably going to be very interesting to you!
Ok, 