Comm.makeJsonRequest: How to add POST data?

Hi all,

Has anybody figured out how to perform a POST with data?

I want to use a web service that only accept POST - not GET - and want all argument as POST data - not URL arguments.

Looking at the definition of makeJsonRequest, I guess there can be an option hidden somewhere. But...

- (Object) makeJsonRequest(url, request, options, responseCallback)

To use Garmin Connect Mobile as a proxy to the web, use makeJsonRequest(). The request is asynchronous; the responseCallback will be called when the request returns.

Parameters:
url (String) — The URL being requested
request (Dictionary) — Dictionary of keys and values, appended to the URL as a GET request. Can be null.
options (Dictionary) — Dictionary of options. Can be null. makeJsonRequest does not currently support any options. Future options are TBD.
responseCallback (Method) — This is a callback in the format function responseCallback(responseCode, data); responseCode has the server response code, and data contains a Dictionary of content if the request was successful.
  • Former Member
    Former Member over 10 years ago
    I don't have an answer, but I think adding the ability to POST is needed to access a lot of JSON restful services. Hopefully the options parameter is hiding this functionality :-)

    Contemplating a Phillips Hue widget but won't be possible until a JSON post can be done.

    From the API SDK

    Lets’ start with the “on” attribute. This is a very simple attribute that can have 2 values: true and false. So let’s try turning the light off.

    Address http://<bridge ip address>/api/newdeveloper/lights/1/state
    Body {"on":false}
    Method PUT
  • Yeah, I started looking at implementing a SmartThings client (which can control all sorts of stuff from outside your home network, including Hue devices, and integrates with IFTTT), but without post support that is really a non-starter. Of course I could always write a mobile application to reformat my requests, or a web service that reformats and forwards requests, but I'm trying to avoid adding an additional layer of complication and any security issues that would arise as a result.
  • I would love to see the following options for makeJSONRequest:

    • :method - the HTTP method - defaults to "GET"
    • :data - any data to be attached to the request - possibly a dictionary as a common case
    • :headers - a dictionary with HTTP-headers to be added to the request - e.g with encoding, authentication, cookies, if-modified-since, etc...


    Likewise, an additional dictionary argument on the callback with all response headers would be perfect.

    This way I think I can implement all the relevant protocols as I see them right now
  • POST isn't supported by makeJsonRequest yet, but we do have a task to add this at some point in the future. Travis already hit on the idea of creating a mobile app or web service to handle this, which is probably the best solution as things stand. In the meantime, I'll add some of your comments to our ticket for consideration.
  • POST isn't supported by makeJsonRequest yet, but we do have a task to add this at some point in the future. Travis already hit on the idea of creating a mobile app or web service to handle this, which is probably the best solution as things stand. In the meantime, I'll add some of your comments to our ticket for consideration.


    -1 on the mobile app!

    Creating a mobile app "just" for this, seems very expensive to me! And adding an extra component - with all the things that can go wrong - is really not a good idea.

    I know your development resources are limited, but considering the many JSON services out there - including those of Google, Yahoo, Twitter, and many many more - and the possible applications and widgets.... And most of these services require OAuth which in turn requires HTTP POST support...
  • Former Member
    Former Member over 10 years ago
    -1 on the mobile app!

    Creating a mobile app "just" for this, seems very expensive to me! And adding an extra component - with all the things that can go wrong - is really not a good idea.


    +2, Yes an App which is just a proxy doesn't really seem like a good solution for both developers and users. The iOS side means the App must be submitted to Apple and reviewed which takes at least 10 days and not sure how Apple will review it as it's uncharted waters. Then you need an Android version which also must be created.

    Connect IQ needs needs "cool" apps to showcase on the store without making it to hard for users/devs to facilitate that.

    A Phillips Hue app would be very popular no doubt and just needs a JSON post added to the SDK for someone to build it!
  • I definitely understand that an additional layer is not ideal. The addition of POST is something we're looking at, and I'll continue to throw support behind it on your behalf. I can't make any guarantees--there may be technical reasons I'm not familiar with that make adding POST support impractical right now--but at least know that you're being heard.

    It's great to see the interest and the passion in the Connect IQ developer community already. I really appreciate your comments!
  • I definitely understand that an additional layer is not ideal. The addition of POST is something we're looking at, and I'll continue to throw support behind it on your behalf. I can't make any guarantees--there may be technical reasons I'm not familiar with that make adding POST support impractical right now--but at least know that you're being heard.


    Thanks - very good to hear!

    It's great to see the interest and the passion in the Connect IQ developer community already. I really appreciate your comments!


    We all have a lot of ideas that tests the limits of the platform :-)
  • POST would be very useful!

    I would like support for 'https://', too. But that is a whole lot more work than to implement POST ;)
  • POST would be very useful!

    I would like support for 'https://', too. But that is a whole lot more work than to implement POST ;)


    HTTPS should be supported on hardware, but it's not on the simulator. It's on our list to fix that.