Support nexus default spec

First, this looks great. Thanks for making it.

Is your feature request related to a problem?

I attempted to use a Nexus OSS spec, but was unable to do so for a couple of reasons

schemes is required to be set on schema (nexus should probably solve this)
host is required to be set on schema (nexus should probably solve this)
$ref missing causes complete failure "$ref": "com.sonatype.nexus.ssl.plugin.internal.rest.ApiCertificate" is missing on spec which causes a complete failure, on version 3.20.1 of nexus (nexus should probably solve this)
basePath contains ending / which results in // on resource requests (nexus should probably solve this)
Property "attributes": {"type": "object","additionalProperties": {"type": "object"}} is not supported expecting a $ref, on version 3.20.1 of nexus
Only {id} and {x-terraform-id} are supported as default identifiers, nexus uses {name}
Most GET requests are for lists so very little support for data source (nexus should probably solve this)

Example:

As an OpenAPI Terraform User
I want to point to a nexus swagger spec (i.e. https://nexus3.onap.org/service/rest/swagger.json)
So that it can be managed using this provider without downloading spec and manual modifications

Describe the solution you'd like

Maybe its feasible for this provider to fallback to schemes and host parsed out of the OTF_VAR_nexus_SWAGGER_URL when not specified on spec
Would it make sense to enable a config that only warns about missing $ref?
Would it make sense to support "attributes": {"type": "object","additionalProperties": {"type": "object"}}?
Would it make sense to support GET requests of array that respond with {id}, {x-terraform-id}, {name} as valid data sources, maybe a generic filter?

Acceptance criteria

Ideally it should be possible to point to a nexus swagger.json and just have it work

Example:

Scenario: As an OpenAPI Terraform User
Given A swagger-url https://nexus3.onap.org/service/rest/swagger.json
When data "nexus_repositories_v1" "maven" { name= "maven-public" }
Then data.maven.name is available

Describe alternatives you've considered

None really, just a quick thought from my initial usage/attempt

Does terraform filter apply for get requests on this provider? Is the issue that only {id} or {x-terraform-id} is supported?

data "nexus_repositories_v1" "mvn" {
  filter {
    name = "name"
    values = ["maven-public"]
  }
}

Additional context

Trying to do this with a docker container: docker run --rm -it 8081:8081 sonatype/nexus3:3.21.1

Checklist (for admin only)

Don't forget to go through the checklist to make sure the issue is created properly:

[ ] I have added a corresponding label (feature request) to the issue (right side menu)
[ ] I have added this issue to the 'API Terraform Provider' GitHub project (right side menu)

Hi @juliostanley , thanks for raising the issue and documenting it so well! I am currently on a trip with no access to my laptop and won’t be able to look into this until later in March. The points raised though seem doable and reasonable so if you would like to take a crack at it pls feel free to do so. I’ll be happy to review the changes and pair if needed.

Answering some of the bullets below:

Maybe its feasible for this provider to fallback to schemes and host parsed out of the OTF_VAR_nexus_SWAGGER_URL when not specified on spec.. Sounds good and aligned with the openapi spec (https://swagger.io/docs/specification/2-0/api-host-and-base-path/). If the host/schemes are not provided in the document the spec says that the default should be the scheme/host where the document was served.
Would it make sense to enable a config that only warns about missing $ref? I am not sure if this could potentially cause undesired outcomes for the user. The idea behind failing close is to notify the provider that something in the spec is wrong and should be fixed. Question: what would be your expected behavior if spec doc contained a resource that is missing the ref for the model, the plugin would not fail and the user tried to provision such resource?
Would it make sense to support "attributes": {"type": "object","additionalProperties": {"type": "object"}}? Are you thinking of support for hashmaps (https://swagger.io/docs/specification/data-models/dictionaries/)? I may need a bit more context to understand this bullet. Would you mind fleshing the use case out? It will help too if you could put together what would be the expected internal terraform schema representation. Thx!
Would it make sense to support GET requests of array that respond with {id}, {x-terraform-id}, {name} as valid data sources, maybe a generic filter? The extension x-terraform-id was added to provide flexibility and enable setting any property schema as the unique identifier. If in the case of nexus that is the {name} property, would it make sense to add the extension to that property in the schema instead? Pls let me know if I missed anything here.

Hope the info above helps.

Dani

dikhan / terraform-provider-openapi