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.
For that you'd actually rather go for a PUT request 
The distinction is not actually artificial, but clearly reflects the primary intention behind the request. The fact that one kind of request can be "abused" for the same kind of task as the intended request type is the "artificial" thing.
1 Like
To keep this short (considering this has been discussed in length before...)
Yes, it would be possible to implement function calls to work with GET requests. You'd have to break the REST principles for it thought, which I for one can't seem to find a valid enough reason for just yet.
It's not so much about the size as it is about what you intend to do with it.
If 'speeding up development' depends on abusing certain conventions, then maybe you're going at it the wrong way. The fact that a browser just so happens to use the same 'thing' (GET) for it to work is a happy coincidence, but does not make a browser a development tool as such.
There are various other routes you can take to call these functions without depending on breaking REST. There's the CLI (which is a good thing to install regardless), Particle Dev, and countless webpages made by community members that will allow you to quickly and easily request variables and trigger functions as needed. I've linked you to mine before, but here's one by @suda. Heck, some people even made apps for this specifically.
Any other reasons why we'd definitely need GET to work as POST that we might have overlooked in this, and previous, discussions?
1 Like
I think it is an interesting discussion, but apparently exhausted by others before me, so I’ll just dump a couple of final thoughts. I accept that the HTTP/RESTful conventions have been adopted here.
I agree, browsers are poor tools for trying to tag a request as “GET”, “PUT”, “POST”, etc. I’d probably be happy if browsers had a special parameter you could add: …?requesttype=PUT&… or even a special URL syntax: …?GET?param1=value1&…
The request types (GET, PUT, …) basically allow you specify a resource and indicate different actions, in a sense “overloading” a URL. There are some good arguments for it, particularly preventing web crawlers from unintentionally triggering unwanted actions (they could still do it maliciously).
I might argue that a “typeless” protocol could leave it up to the developer to specify a “type” parameter as part of the request to direct the processing of the URL if the developer wanted to overload the URL with multiple actions.
I might argue that a certain web service, such as one that returns a random number, has no meaning if called as a “PUT” or “POST” request. In other words, the built-in orthogonality of the mandatory request type is counter to the entity itself. GET, PUT, POST, DELETE, etc. imply a resource is of a certain form that can be created, updated, deleted, etc. In a sense, such orthogonal typing forces a taxonomy on resources that they may not belong in.
The most compelling argument to me for such request typing is if it enables web server designers to create generic web servers that can process a request more efficiently, making optimal use of their resources, just by knowing if a request is of type GET, PUT, etc. That would be a powerful incentive to adhere to the protocol, especially if I am hosting such a server. I could still ignore the protocol in my web application if I wanted (as many do), but it might cost me.
Because Particle is hosting the servers, it makes perfect sense they would want to adhere to a protocol that potentially is more efficient. I’m sure other design simplifications can result as well. I’ll just have to round up the tools that make it easier to test my application given this protocol.
-SB