Support the IdentityProvider API in this client

[robotdan]

Currently due to the serialization / de-serialization complexity of the IdP APIs, they are omitted from this client.

Here are the APIs we are skipping at the moment:
https://github.com/FusionAuth/fusionauth-client-builder/blob/462c2ca09bb291581164f383428ae276645ace55/src/main/client/go.client.ftl#L186

If we could figure out how to make this work in Go, we would add them.

Here is an example solution provided by @MCBrandenburg https://play.golang.org/p/7ZBAbrDo98w

[matthewhartstonge]

Here's my sample solution: https://play.golang.org/p/RX_mRBsSUQD

Generally, Gophers tend to code everything into the expected payload, with the expectation that developers are (...hopefully...) smart enough to switch/case on type for the fields they require directly.

As long as you API docs specify this, then it's a case of Read The Manual if they use the SDK wrong.

Having to step through and unmarshal bits of a response manually is much more painful than having all the data there ready to use.

For truly custom user JSON, (for example, user.Data) where you currently have map[string]interface{} you could use json.RawMessage, that way developers themselves can marshal/unmarshal into their required types as needed. Which means the main bit (what FA) cares about is marshalled out into useable data.

(For user data I ended up json.Marshal'ing user.Data to JSON so I could then json.Unmarshal to MyType{} as map[string]interface{} is a pain to work with in terms of complex objects/switch casing/type switch casing and/or marshalling each piece out, I then do the marshal/unmarshal dance in reverse to get me a map[string]interface{} before pushing the data back up 😄 so json.RawMessage would be a win for me here too 👍)

Hope that helps add to the conversation! 🎉

[robotdan]

Thanks for the great detail and suggestions @matthewhartstonge - appreciate it!!