Cloud API Docs Up to date?

Cloud
1

I’m trying to use the cloud API and the docs say to trigger a diagnostics do this

"https://api.particle.io/v1/diagnostics/0123456789abcdef01234567/update?access_token=1234"

However, when doing that with my correct access_token and device ID i get:

{"ok":false,"error":"Not Found"}

if I run the command for fetching the last diagnostics data, it returns fine.

2

Hi, sadly, I get the same results.

Maybe @mstanley can help here?
thanks!

3

Ditto.

4

Hey everyone,

A question for you all. How is it you all are performing the request call? (cURL, web app, etc?). I’d be interested in seeing the structure of the requests with emphasis on GET or POST.

I just wrote a quick webapp to reproduce. I get the behavior you’re all seeing with GET, but receive expected behavior with POST.

Checking our our device vitals docs seems to suggest the endpoint as being POST, but the docs seem to show it as a GET request in the example which I don’t think is actually a valid endpoint.

If I can get confirmations this is being run as a GET, but works with POST, I think this is simply a docs issue and I can make a note about this.

2 Likes
5

I was running this as a GET and got the issue:

$ curl https://api.particle.io/v1/diagnostics/893794289347892789342/update?access_token=978923789427894789378927892777777

{"ok":false,"error":"Not Found"}

Now when I send a POST, it works, thank you @mstanley!

$ curl -X POST https://api.particle.io/v1/diagnostics/12378457682234/update?access_token=2934928748927984729837422223423477777

{"ok":true}

FYI @armor @marcusone

6

sorry, i forgot to test as post, as was too focused on docs so though the “post” was referring to the example above. I guess technically POST is more accurate for RestAPI calls when sending a command and not requesting a value. Thanks.

7

No worries. Our docs actually reflect the GET parameter, so it’s not outdated so much as it is a misrepresentation of cURL commands. An internal issue has already been filed for this. Expect it to be fixed sono. :slight_smile:

1 Like
8

Scrap that - see two posts bellow

Just to be awkward, I'd think the documented request type should be the way to go - don't change the docs to fit a "misguided" implementation (apart from a note for now till it's repaired). The actual intent of that request *suggest* a GET rather than POST? I want to *get* the information, I'm not posting any interesting data to the cloud to work with. If in doubt about the intent then GET would be the common "default" endpoint most people would expect to be there. In the early days of Spark we had long and wide discussions of *why* `Particle.function()` requests need to be POSTed and the narrative was around *intent* so breaking that narrative now seems ... well ... inconsistent at least ;-)
1 Like
9

I believe the "Restful" way is POST, as you are sending a command to the server, which its response is just "ok". You then need to do a GET to get the information. So does make sense when I take the time to think :slight_smile:

True... no "interesting" data is sent.. but its a command, as this request isn't to "GET" any information from the server.

So I believe its just a doc update that's needed?

2 Likes
10

Yup, you are correct, I just lost the connection that the result will be published and not returned :blush:

1 Like