OPNSense API

[ansibleguy]

Greetings.

This is just a generic thread to talk about the OPNSense API

[ansibleguy]

Greetings @fichtner - you seem to have some good insights in the ins-and-outs of the OPNSense system.

I just want to casually ask your opinion to some problems I've encountered:

(To be clear: I totally understand that these problems CAN be handled on the client-side. But IMHO if an API is available for external use - it should be consistent.)

• In some API endpoints the key-naming is just awful.. (not to say random)

  Current example: IDS

  # it starts with lowercase/snake-case
  interfaces
  homenet
  toserver_groups
  
  # then goes to camelCase
  defaultPacketSize
  
  # and then to PascalCase
  UpdateCron
  AlertLogrotate
  

  This makes me loco.. :'D

• Some endpoints have inconsistent input/output 'formats'.

  Example 1: The 'network' vs 'subnet_cidr' in Vip
  Problem: interface_vip error 'A network address is required' #34

  # box input
  "network": "192.168.0.1/30",
  
   # box output
  "subnet": "192.168.0.1", "subnet_bits": "30",
  

  Example 2: The 'version' in IPSec-Connection

  # box input
  "version": 0,  # or 1 or 2
  
  # box output
  "version": "IKEv1+IKEv2",  # or 'IKEv1' or 'IKEv2'
  

• If an API-Call fails to validate - it sometimes return a 2xx status-code (not all endpoints)

  As seen in my API - response check it would be easier to handle if that would be the case.

  (Note: It's been a while since I've tested the API endpoints without this added logic - it could be fixed now, but I do not think so)

• I've seen many more. But as I got the feeling (from some ticket responses) that these are 'acknowledged' - I did not report them.

---

I would guess these inconsistencies exist because of the internal structure of the OPNSense core-code.. What would you say?

I am really glad that OPNSense enables us to use its API as projects like this one would not exist without it.
Also OPNSense is a great product!

BTW: Would be open for E-Mail communication if preferred 👍🏼