[Question] Support for POST (input) model without id

[lukoyanov]

Is your feature request related to a problem?

No

Describe the solution you'd like

I'm trying to use terraform-provider-openapi with one of our already existing services. The problem is that all our APIs a designed a way where POST (input) model doesn't have an id, while output model does have it. So we use separate model definitions (output model inherits all fields using all-of feature of openapi/swagger schema).

So the question is how can I use this terraform provider without changing my openapi spec?

Checklist

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

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

[dikhan]

Hi @lukoyanov , thanks for raising this question. Unfortunately, that use case is not supported at the moment (v0.10.0 of the provider). However, it sounds like a legitimate scenario (I know GOA handles the definitions in a similar way with payloads and media types) and I would be happy to accept a PR that covers that functionality.

Off the top of my head, the following updates would be required to be able to support this use case:

• The provider would have to support two ways of configuring resources.

  • the current model where the resource shares a common schema definition (including input properties, computed and optional) for all the operations.
  • the new proposed approach, where the POST operation only has a definition for the inputs, and the GET contains both the input + the computed properties including the ID.

• Configuring the resource schema: Ability to detect at runtime which option applies to each resource, for the second option I can think that perhaps if the POST schema definition does not include an ID property, the approach taken by the provider would be the second. Hence, it will rely on the GET's operation schema to configure the resource terraform schema.

• Performing the resource creation call: After the POST is called, instead of relying on the response given, there will be a subsequent call to the GET operation where the data in the response will be used to populate the state of the resource. One thing to keep in mind here, is that the GET operation must return both the computed values as well as the input from POST, otherwise terraform will complain with diffs.

I may be missing few more things that may be required, but the above covers some bits to keep in mind for the design phase. I am happy to work with you on this if you want to take a crack at it.

Thanks!
Dani

[lukoyanov]

Hi @dikhan! Thank you for a detailed answer. Well, I'm sure that it would be better to pick it up for a more experienced in golang contributor than me =)

[dikhan]

hey @lukoyanov ,

Just wanted to follow up with this, I have been working on a branch that adds support for this use case and would be great if you could validate on your end whether it covers this issue.

This is the PR opened for it: #295

Let me know if you have any questions.

Thanks,
Dani