REST API: various null fields violate netcup-defined OpenAPI spec

I'm guessing there will likely be other endpoints that violate spec like this, and the API should be reviewed top to bottom.

I'm trying to implement rdns routines:

$ go run cmd/netcup/main.go rdns delete ...

$ go run cmd/netcup/main.go rdns get ...
Error: decode response: decode application/hal+json: decode RdnsIpv4: callback: decode field "rdns": unexpected byte 110 'n' at 8
exit status 1

When I look at the actual response directly:

$ curl -s -H "Accept: application/hal+json" \
  -H "Authorization: Bearer $(go run cmd/netcup/main.go auth print-access-token)" \
  -X 'GET' \
  'https://servercontrolpanel.de/scp-core/api/v1/rdns/ipv4/...' | jq
{
  "rdns": null
}

This is a problem because the OpenAPI spec does not say this is possible.

$ jq '.components.schemas.RdnsIpv4' openapi.json
{
  "type": "object",
  "properties": {
    "rdns": {
      "type": "string"
    }
  }
}

The spec is missing a nullable which you can read about here: https://swagger.io/docs/specifica…ata-types/#null

Because the string data type is missing a nullable attribute, OpenAPI generator tools, like ogen in my case, generates:

type RdnsIpv4 struct {
    Rdns OptString `json:"rdns"`
}

Which only allows this field to be a string or absent, but not null.

Hi [netcup] Sarah G. - tonight I was going to work on implementing `netcup servers get ...` and `netcup servers set ...` but found another similar nullable OpenAPI spec violation:

$ curl -s -H "Authorization: Bearer $(go run cmd/netcup/main.go auth print-access-token)" \
  "https://www.servercontrolpanel.de/scp-core/api/v1/servers/......" | jq '.serverLiveInfo.interfaces[0].vlanId'
null

This of course again is not deemed possible in your spec. All your endpoints should be reviewed and either the spec fixed or server behavior fixed.

Do you already have engineers assigned to work on the various REST API bug fixes? Would it be possible to get a soft timeline on the remediation efforts?

I will pause on my netcup CLI tool and OpenTofu (Terraform) provider work until we hear back on the state and timeline of further REST API development, and look forward to resuming when the API is actually ready for production use.

Thank you! 🦆 (I have seen the duck emoji used in many places in the forum, what does it stand for? )