API Improvements

[Jixabon]

API Improvements Discussion

I'm looking to work on some improvements to the API and opening this issue as a central place to open discussion about what my ideas are and what others ideas are. I intend to update the issue with anything that is decided on to prevent confusion when scrolling through the replies.

To get things started here is what I have in mind so far.

In Progress

• Add /system.raspapVersion
• Add /system.usedDisk
• Add /ap.frequency_band
• Add /clients endpoint
  • datapoints
    • active_clients_amount
    • active_wireless_clients_amount
    • active_ethernet_clients_amount
    • active_clients
      • will have same data as the interface specific list but an additional data point of "connection_type" with value of "wireless", "ethernet" or "unknown"
  • keep the existing /clients/{interface} endpoint for ability to get a specific interface's data

Ideas

• More service status datapoints to have a straightforward central way to see how/if things are running. Would likely go in /system and join hostapdStatus
• WiFi client
  • list of networks available to connect to
  • A POST endpoint to set what to connect to

Other things to note

• Renaming datapoint names to be consistently cased and predictable (eg snake case or camel cased).

[billz]

Love it! Looping in @NL-TCH who originally created the API to get his thoughts.

Several users have asked about extending the API to include POST methods. Managing WiFi client connections is a great starting point. Perhaps then start/stop AP? These are basic but essential functions.

[NL-TCH]

Amazing work @Jixabon
Thanks for the ping @billz as I am way to busy to work on the api myself I would like to be a reviewer and if time allows it tester.

Looking forward to your contribution!

[NL-TCH]

@Jixabon while you are at it, please update and check the api-python-modules.
They are listed in the api/requirements.txt and are quite outdated (although no registered vulnerabilities)

[Jixabon]

Just got to thinking, was there a reason that the API went the python route or even a separate service? As I'm going through this and thinking of how to add things there's a lot of reverse engineering the main pages' code. Would it potentially be a good idea to pivot to moving the API into PHP to take advantage of the current code base and maximize code usability and reduce chances for bugs, or at the very least be able to fix things in one place instead of two. Maybe not everything in the webgui code base could be used but I'm sure there's enough to be worth it. It would also reduce the projects overall dependencies.

Could be started in the /src/API or /src/RaspAP/API namespace.

[billz]

@Jixabon excellent point. @NL-TCH may correct me here, but I believe FastAPI was the main driver for Python. It gives us a user-friendly UI and it's, well... really fast. Downside as you've noted is it does require code duplication. The GET requests are pretty straightforward, but I think the API endpoints that use POST will need to duplicate a lot more PHP code. There are many well established API frameworks for PHP. I'd lean toward something minimal + lightweight (possibly Slim?) over a kitchen sink type framework. Open to ideas / suggestions!

[NL-TCH]

Completely agree! I just don't like php lol😉
But yes api integrated into php to solve the reverse engineering and code duplication is the mature way to go!