Thank you for this REST provider which is proving very useful. I face an issue during import, partly because the API I deal with is not so REST compliant and partly because of the limitations of the import code.
The API I request doesn't support path variables and I'm stuck with query parameters. So I have configured my resource with a read_path as ?id={id} which is not pretty but works well during an apply. The problem occurs during import:
If I omit the ?id= prefix in the imported id, the API isn't queried on the proper path and it fails.
If I add the ?id= prefix in the import id like /?id=myId, the import succeeds but then the id of the imported object still contains the prefix which doesn't match the id computed during apply.
In a few word, the id computed during apply and the id computed during import don't match when the read_path attribute is not exactly a path.
I think a good solution that would work for this case but also for the general case would be to automatically preprend the read_path value if any to the id specified during import. That would also allow call the import command without specifying the full path. But I'm not sure you have access to the resource attributes during import.
Another option would be to put a curly brace wrapper around the id in TF import commands. This would be more flexible and also solve the case described in #89. If no curly braces are found, it could fallback to the usual logic, maintaining compatibility.
Examples:
terraform import 'myTfResource' '/path/to/resource/myId' -> usual behavior
terraform import 'myTfResource' '/path/to/resource?id={myId}' -> for my use case
terraform import 'myTfResource' '/path/to/resource/{myId}.json' -> for #89 use case
What do you think of these proposals ? I may be able to write a PR for this but before I need your opinion on this :)
Hi everyone!
Thank you for this REST provider which is proving very useful. I face an issue during import, partly because the API I deal with is not so REST compliant and partly because of the limitations of the import code.
The API I request doesn't support path variables and I'm stuck with query parameters. So I have configured my resource with a
read_path
as?id={id}
which is not pretty but works well during an apply. The problem occurs during import:?id=
prefix in the imported id, the API isn't queried on the proper path and it fails.?id=
prefix in the import id like/?id=myId
, the import succeeds but then the id of the imported object still contains the prefix which doesn't match the id computed during apply.In a few word, the id computed during apply and the id computed during import don't match when the
read_path
attribute is not exactly a path.I think a good solution that would work for this case but also for the general case would be to automatically preprend the
read_path
value if any to the id specified during import. That would also allow call the import command without specifying the full path. But I'm not sure you have access to the resource attributes during import.Another option would be to put a curly brace wrapper around the id in TF import commands. This would be more flexible and also solve the case described in #89. If no curly braces are found, it could fallback to the usual logic, maintaining compatibility.
Examples:
What do you think of these proposals ? I may be able to write a PR for this but before I need your opinion on this :)