What is POST and GET? How do you use them?

You’re welcome, I guess :wink:
Minor questions: what ‘tool’ are you referring to, and what Spark GUI?
Also, depending on what example you’re referring to; one has a topic over here, to which I linked. The other one is something I pulled together with the Javascript SDK just to try it out. More of a personal experiment, which turned out to be pretty useful for testing stuff. Either way, with most Web based applications, you can see the code by right clicking and then selecting ‘view source’. I’ll see if I can add download link for the files to the project sometime soon.
In the mean time, feel free to ask questions, should you have any.

By tool, and GUI, I was referring to the Spark online development page/area, where you end up from “https://www.spark.io/build/”. I’m not sure what Spark officially calls it.

I still need to go look at these closer.

This is what I was referring to.

Oh! That should’ve occurred to me. I’ve used that to occasionally look at HTML code in the past. It just didn’t occur to me that Javascript might also be visible that way.

Right now, since I’m very new to Java/Javascript I’ve been trying to use other ways to talk with/work with my Spark units.

Thank you. This post has explained why I had such a hard time with getting variables working in my IoT rant at https://www.youtube.com/watch?v=1ZYcCXPAMPo&feature=youtu.be

I will start testing GET with my webpage control of the Spark Core at https://www.youtube.com/watch?v=-CyKv4UC1OA. Actually surprised the Spark uses Get for accessing variables since POST is generally considered to be a safer way to send form information. See the following code, If done using POST the access_code would be hidden by posting the variables, however if done using a webform and GET the access_code has to be included in the calling URL. Probably doesn’t matter either way since your Core_ID is always included in the URL when used with a webform.


That ‘GUI’ is mostly referred to as the Web IDE (build), which is also how it’s called in the docs. It’s also being called Spark Build, or even ‘Sparkulator’. Spark has also released an offline IDE not too long ago. It’s called the Spark Dev, and will also allow you to program your Core, as well as displaying your functions/variables. Please do check it out, it’s pretty awesome :)!

The Javascript I’m using is made up of my own ‘stuff’, combined with the Spark JavaScript SDK, so you’ll have to take a look at that as well. You can see that the files are included, but since that’s a minified version, it’ll be hard to read/understand. You’re better of checking the docs to see what those parts of the code are doing. There are even some examples included in the respective GitHub, which can be found by following the examples link here. The examples are primarily targeted towards Node.js, but should work in the browser as well. There are still some small bugs, but I believe those are being thoroughly looked into by @nexxy

Sidenote: Java and JavaScript are as similar as Car and Carpet. They’re different beasts, and although they share a lot of similarities, they should be treated seperately :wink:
Javascript is really useful for web based applications since it’s pretty much universally supported, and more interestingly also the language in which to program Node.js. If you can combine those two (Node.js on server, and javascript in client) you can make some really awesome projects :blush: I’m combining the two in an effort to make a datalogger with a dashboard for my project, which currently looks like this: (data is pushed from my Spark)

Anyhow, should you have any further question, feel free to ask!

@rocksetta, glad I could help.

It’s actually not that surpising that they’ve used GET for getting information. Other than the fact that the name itself implies the function, it’s also how it’s specified in the conventions. Also, you say that:

POST is generally considered to be a safer way to send form information.

That’s where the confusion lies perhaps. You’re not using GET to send information. You’re using GET to request information. POST is used if you’re trying to send information (which is what’s being used for Spark.function() calls).
Compare it with getting your mail out of your mailbox (the old paper version). Either you’re GETting your mail, in which case you’re merely requesting information, or you’re POSTing mail, in which case you’re transmitting information. The mailbox would be the server in this case. When you get your mail, you’re simply taking out information which has been made available through the server, but you’re not actually making it do anything. When you’re posting mail, you’re telling the mailbox:“hey, here’s some information, would you process it, and make sure it’s gets to where it needs to be?”. You’re making the server do something, you’re changing things.
I know that forms often choose to ignore there conventions, but that doesn’t mean everybody should. The fact that you can shoot somebody, doesn’t mean you should, either, now does it ;)? (Even though it might be convient from time to time :p)

sidenote 2: GET and POST have nothing to do with webforms. Webforms is just one of the many things that can make use of either of those methods. Like mentioned in the above posts, there are multiple mays you can make any of the HTML requests.

1 Like

Hello @bko, can the arguments be passed in a single url? For example, if I have the following:

If the function has an input parameter, will i be able to send a value (such as an int or string) after the {function}?

Thank you for your help,

Hi @Anth

You cannot do a POST to call a Spark.fuction() directly from a URL (but you can do a GET to read a Spark.variable()).

If you are using curl, you just pass parameters in the way shown in the Spark doc.

If you are writing your own web page, you can read this tutorial to see how you can do it:

1 Like

Thank you for your help, @bko


Hey all,

I am replying here because I have the same problem.
I flashed this code to my core http://docs.spark.io/examples/ (of controlling led over the Internet).
Than I tried to write to my terminal:
curl https://api.spark.io/v1/devices/MY_CORE_ID/led \ -d access_token=MY_ACCESS_TOKEN \ -d params=l7,HIGH

Instead of MY_ACCESS_TOKEN and MY_CORE_ID I wrote their actual values.

It printed to me:

  "code": 400,
  "error": "invalid_request",
  "error_description": "The access token was not found"
}curl: (6) Could not resolve host: access_token=MY_ACCESS_TOKEN
curl: (6) Could not resolve host: params=l7,HIGH

Instead of MY_ACCESS_TOKEN and MY_CORE_ID it printed their actual values.

What did I did wrong?


Hi @orwn

It looks like curl did not take your parameters with the -d since it thought those were more URLs you want to access. Here are some things that might have been a typo for you:

There is no space between the “-” and the “d” but there is a space between the -d and the next word.

The command as shown in the doc uses the backslash as a line continuation character so that you can write the command on three lines, but you don’t have to do it that way–you can just type it all on one line and leave off the “” characters.


#It worked!!

@bko Thanks you very much!


Just saying that I would prefer if a user could activate BOTH a function and recall a variable in one call to the server. In the example code at http://community.spark.io/t/tutorial-spark-variable-and-function-on-one-web-page/4181, it looks like only one call but it is actually making both a POST and a GET.

I prefer using POST as it is less easy to hack. GET commands have all your private information in the URL.

For that mater, has anyone got the Core Name working in a POST or GET instead of having to use the Core_ID. Using your hard to change Core_ID in the URL is just a really horrible idea.

P.S. Use localStorage to store your Core_ID and access_token, that is much safer than hard coding all this information into your webpages.

The core ID is not meant to be a secret and they are published in the public event stream, for instance. I mention in the tutorial you linked to that you should not put your secret access_token where others can read it and a proxy server is one solution. I think eventually the name feature will be used by the Spark cloud but for right now it is by core ID. You can use the “Authorization: Bearer” header with GET and PUT so that the token is not in the URL but it really doesn’t change the security since it is still easy visible in the browser debugger.

The difference between GET and PUT is just good object-oriented hygiene, in my opinion.

1 Like

So if GET is to get information and POST is to send information, how can we have the Spark Cloud Server not reply to a POST. I want to speed up sending analogWrite information to my Spark Core (I don’t care if the occasional AnalogWrite gets lost). I wish to send 2 - 5 AnalogWrites in under a second (only for a couple of minutes). Presently I wait for AJAX to receive the reply before sending the next AnalogWrite (by calling a function of course). My wait times are between 500ms and 900ms. Without waiting for the reply I could probably get to about 200ms between sending POSTS.

So any idea how to turn off the reply feature on the Spark Cloud. I think it is more complex than just not setting a “return” variable.

You could try not waiting for the response?
Also, why would you like to send requests at that frequency? It’s not really meant to be spammed. If you could tell us what you’re trying to do, then perhaps we could offer some better alternatives?

I am controlling a toy car with the Spark Core, from a web page. Most of the time you drive straight (one analogueWrite to set the driving speed) but occasionally you have to correct your direction and need a flurry of AnalogWrites to the steering motor. I am researching sockets but really want to keep things easy for beginners.

If you can think of an easy web socket that might work I would have a look at it.

Why can we not just use web browser URL to issue a Restful GET request? We have a REST web service running under Tomcat and we use the browser that way.

Also, can we not use a “GET” request to call a function, relying on ordered mapping of parameters?

You can…

Sinds that’s more of a hack that goes against the REST protocol/rules/whatever. GET only gets data, it doesn’t change anything. If you do want to do that, then use POST, which is made for that purpose.
Sure, it could be done, but that’d require programming this ‘sketchy hack’ into the backend, which is questionable.
What’s your opposition against using POST based on?

1 Like

And if you read the top of the thread, @Moors7 would not have had to repeat the whole thing again, since this is already answered in exactly this thread - hence the title

Or here, you find a long discussion why the technical decision to use POST for Particle.funcion() calls stands (and won’t be changed - despite the OP’s viewpoint)

1 Like

Thanks for confirming a web browser works for a GET request. I was having trouble getting it to work for other reasons, but wasn’t sure if it was related to using a browser.

I know curl has syntax for creating POST requests, but a browser is a universal client and very handy for testing basic functionality; I don’t know of a native way to generate a POST request with a browser. I have always felt the distinction between GET and POST for sending small amounts of data is somewhat artificial. POST is particularly strong for uploading large amounts of data, such as uploading files, sending blocks of text, etc. GET seems quite efficient at transmitting simple parameter values. What is done with the parameters after REST decodes them is up to your application. I agree that changing the state of your application with a GET request goes against certain “rules” (idempotent, etc.) possibly, but practically, it would be very useful if we could link function calls with “GET” style requests and speeds development.

My question was mainly confirming a web browser should be able to invoke a GET request to our Particle device via the cloud and whether a facility for using GET as POST was implemented, not debating the decision of POST vs GET. And as I scramble to absorb all the different aspects of engineering with these devices, I may miss some very useful discussions that have already taken place.