Use IDs provided as URLs

[stephenpaulger]

See also #205

This PR solves two issues I've experienced.

• Some APIs return the ID as part of a structure of URLs to the resource or sub-resources.
• Some APIs don't return the object in the body when creating or update the object but provide a redirect to the newly created object.

This change

• permits the attribute specified by id_attribute to be a URL and assumes the ID is the last element in the path.
• Follows Location response headers to allow the provider to obtain the ID of newly created objects.

I have included a unit test for function that extracts the ID from a URL but not for the redirection functionality, if you have advice on how to implement that test I'm happy to try to add one.

[DRuggeri]

Thanks, @stephenpaulger - I like this idea quite a bit! Great PR

I'm curious about the implementation, though. The provider expects an object that gets created to be at a predictable path that can be queried for state (read_path). I don't think this prevents that from working, but I sense a limitation in that the Location header and format may be API-specific to know the proper way to parse it. Would it be reasonable to assume that the Location header points us to something that ought to look exactly like the read_path? If so, we could then parse read_path as something of a "template" to know where in the header's value the ID can be found.

The more I think about it, the more I lean toward the direction that an API should probably provide a 202 and Location to the read_path... but I don't know what I don't know regarding the specific API you're working on :-)

[rpersee]

I'm facing the same issue with an API that also returns the created resource path in the "Location" header. I've rebased this PR to solve the conflicts: https://github.com/rpersee/terraform-provider-restapi/tree/id-as-url
@stephenpaulger maybe you could update your PR with this fork?
Would these changes be accepted @DRuggeri ?

[DRuggeri]

@rpersee, I think I grok the idea behind it but it may be wading too deep into the territory of unique-to-one-specific-API for this provider. This doesn't seem like a common REST API pattern - or at least, not one I have come across.

Are there some APIs out there you can share so I can do some more reading?