Skip to content

API Usage Options

snorklerjoe edited this page Aug 29, 2022 · 3 revisions

So, you're a team, maybe you've registered through the webapp. Regardless, here's how you can choose to send in your data from your microcontroller- These are the currently available options (likely to expand as time goes on), ranked from easiest to hardest:

  • Use the CircuitPython API wrapper
    • This should work with any wifi-equipped circuitpython microcontroller.
  • Use the Arduino IDE API wrapper
    • This should enable you to use the Arduino IDE or PlatformIO to program ESP32 and ESP8266 microcontrollers
  • Implement your own means of using the API!
    • This option is available to those who are feeling ambitious. If you aren't satisfied with the above options and want to learn about what goes on under the hood of the API wrapper libraries, read on! This system uses what is called a RESTful API (which is, admittedly, probably not perfectly RESTful). There are three main considerations to implementing your own means of sending your data-
      1. Connect to the WiFi access point
        • This is going to be largely platform-specific. You probably get the picture, though.
      2. Authorization
        • Client verification: Clients should use HTTP Basic Authentication to identify with the "username" being the case-sensitive team name exactly as it was registered and the "password" being the pre-shared secret code received upon sign-up (again, typed exactly as it was given). There are libraries out there to help with this; in fact, most http libraries have support for basic authentication so this part can likely be done fairly easily with standard libraries.
        • Server verification: Clients should confirm that the server is authentic (to prevent another team from cheating by pretending to be the server and receiving other teams' data) by verifying the server's public SSL certificate. This certificate will be self-signed instead of from a certificate authority due to the API being locked to a private network. The idea is fairly simple, store the server's public SSL certificate or a hash thereof and then complain/don't send any data if the certificate changes!
      3. Resources
        • Now to the data part! use a POST request to the path /data to send your data- Look at one of the above, existing, API wrappers for more specific details Testing your own implementation- Remember you can always clone this repo and run the server locally on basically any computer with a WiFi card capable of AP (access point) mode for testing!