Hi. I would like to see the exact format of s string that will update a heed value when I paste it in my browser. My problem is that I cannot find any examples in the API Docs. I have tried many variants of the following string, but so far without any luck:
(Does not work:) https://io.adafruit.com/api/v2/xxxxxx/g ... ds/h/post/{"value":"76.4"}/X-AIO-Key=My_AIO_key
Best regards,
Kristian.
How to format a feed value message to IO.Adafruit
Moderators: adafruit_support_bill, adafruit
2 posts
• Page 1 of 1
Please be positive and constructive with your questions and comments.
-
krmped - Posts: 2
- Joined: Tue Oct 16, 2018 9:47 am
Re: How to format a feed value message to IO.Adafruit
Hi krmped,
If I understand you correctly, you'd like to visit a URL with your browser and have IO save data as a result?
Short answer:
Unfortunately, due to the way the API is built and the way browsers work, that's not possible in one step. Browsers, when loading a URL (like in your example) always make HTTP GET requests, but the API requires data creation (and any other request that modifies records in IO) to be HTTP POST requests.
Longer answer with demo code and explanation:
If you want to drive IO in a system that uses URLs and GET requests directly--for example, NFC tags or QR codes--you can use a simple web-app as an intermediary. I've built an example app that demonstrates that here: https://glitch.com/edit/#!/io-get-request-demo.
In this case, the app presents two URLs, https://io-get-request-demo.glitch.me/9JWUhz2MDqlkmrtJzTTacw and https://io-get-request-demo.glitch.me/off. When you follow those links, the app publishes a 1 or 0 to IO, respectively. The actual URL, "/9JWU..." you use is arbitrary and set up in server.js. This sketch has one obscure / randomly generated URL, and one that's simple.
The big (big big) problem with a setup like this, is that it's indiscriminate in terms of who is visiting the URL and for what reason. The risk of losing control of your Adafruit IO credentials is much lower than your example (which makes your key visible to anyone who can see the link), but leaves you open to web-crawlers and any other automated link-following scripts. A fun experiment is posting a link like, "https://io-get-request-demo.glitch.me/9JWUhz2MDqlkmrtJzTTacw" into a Facebook, Twitter, or Slack message and watching how many visits you get. Wait long enough and you'll also get search engines crawling. They avoid HTML forms, but anything in an <a href="..."></a> tag is going to be loaded.
If you set up a system that publishes data based on simple GET requests, you have to come up with some way of limiting how many requests it can make to avoid accidental denial of service attacks. That's the biggest reason why we don't allow data creation/modification/deletion requests via URL-pasted-into-the-browser. The second reason is that encouraging or allowing API keys in shareable URLs encourages people to make their credentials too public.
- adam b.
If I understand you correctly, you'd like to visit a URL with your browser and have IO save data as a result?
Short answer:
Unfortunately, due to the way the API is built and the way browsers work, that's not possible in one step. Browsers, when loading a URL (like in your example) always make HTTP GET requests, but the API requires data creation (and any other request that modifies records in IO) to be HTTP POST requests.
Longer answer with demo code and explanation:
If you want to drive IO in a system that uses URLs and GET requests directly--for example, NFC tags or QR codes--you can use a simple web-app as an intermediary. I've built an example app that demonstrates that here: https://glitch.com/edit/#!/io-get-request-demo.
In this case, the app presents two URLs, https://io-get-request-demo.glitch.me/9JWUhz2MDqlkmrtJzTTacw and https://io-get-request-demo.glitch.me/off. When you follow those links, the app publishes a 1 or 0 to IO, respectively. The actual URL, "/9JWU..." you use is arbitrary and set up in server.js. This sketch has one obscure / randomly generated URL, and one that's simple.
The big (big big) problem with a setup like this, is that it's indiscriminate in terms of who is visiting the URL and for what reason. The risk of losing control of your Adafruit IO credentials is much lower than your example (which makes your key visible to anyone who can see the link), but leaves you open to web-crawlers and any other automated link-following scripts. A fun experiment is posting a link like, "https://io-get-request-demo.glitch.me/9JWUhz2MDqlkmrtJzTTacw" into a Facebook, Twitter, or Slack message and watching how many visits you get. Wait long enough and you'll also get search engines crawling. They avoid HTML forms, but anything in an <a href="..."></a> tag is going to be loaded.
If you set up a system that publishes data based on simple GET requests, you have to come up with some way of limiting how many requests it can make to avoid accidental denial of service attacks. That's the biggest reason why we don't allow data creation/modification/deletion requests via URL-pasted-into-the-browser. The second reason is that encouraging or allowing API keys in shareable URLs encourages people to make their credentials too public.
- adam b.
-
abachman - Posts: 242
- Joined: Mon Feb 01, 2010 12:48 pm
2 posts
• Page 1 of 1
Please be positive and constructive with your questions and comments.