-1

I have a working HTTP RESTful API that will receive an ID, then check against data in the database. Based on the status of the record and related records it will then return either state errors or if everything is ready to begin it will return some information about the records. It has some other functionality as well but my issue is our device we are using to collect this data does not have access to WiFi, we are planning on testing a 2G cellular solution but I know an HTTP request will be far too slow if it even completes.

What lightweight protocol can my device send a 36 char UUID to a server and get a JSON response back. I have been exploring information about MQTT and COAP but don't see much info on asking another device about a specific ID of a record it's more like ask for a hardware's status.

Furthermore, if there is a solution I can get to interface with my existing API this would be ideal.

Thanks for any help.

hardillb
  • 54,545
  • 11
  • 67
  • 105

1 Answers1

0

I'm not sure why the 2G cellular solution wont play well with HTTP(S).

according to another SO answer the size of http is:

Request headers today vary in size from ~200 bytes to over 2KB. As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common.

And according to wiki you can get up to 40kbit/s. I'm not really sure what the issue is with using http(s) for this scenario.

If you use something like UDP it can be quicker and is smaller however, it's not as reliable as HTTP due to packet loss possibilities. Not to mention you can also apply gzip or another form of compression on the HTTP request to make it even smaller.

minor update

If that data is not needed right away you can do it hourly or half day batch uploads, store all the data in a local db and at certain time intervals do 1 main HTTP request that is a bit bigger but will have all the data? I'm not fully sure what your requirements are but HTTP should be fine for your case over 2G

Andrei
  • 1,196
  • 1
  • 11
  • 25