Add Sideloading support

[senpos]

Hi,

It could be great to have support for sideloading.

Zendesk Documentation

It is useful when you need extra data for the specific entity, like, "slas" for the "ticket".
If I understood correctly, it is not possible to do at the moment.

[tamccall]

This seems like a fun feature, but i think i need some more information before I could go about implementing it.

Just looking over the the documentation it seems like it might be a little tricky to actually implement, so I would love some feedback before I get started.

Looking at the API it looks like there are a bunch of different options for what can be sideloaded, and that changes api to API.

In order to avoid implementing a bunch of sideloading logic for each api it might be better to emulate the json package and allow the users to pass in the object to marshal the result into.

I'm thinking the API would look something like this when calling the client

var users []User
var groups []Group
ticket, err := client.GetTicket(ctx, 2, SideLoad("users", &users), SideLoad("groups", &groups))
if err != nil {
	return err
}

after calling GetTicket the user and groups lists would be filled with the sideloaded users and groups.

How does that API sound to you @senpos?

[senpos]

Hi @tamccall,

Thanks for your reply.

Sorry, but I am not a mature Go developer, so I won't be able to help you with the design of this feature.

I am coming from Python and similar library for Zendesk just adds attributes to the ticket object if they were sideloaded. I don't know if it is possible to do easily in Go, so I like your approach. :)

[tamccall]

I put a couple of prs together that could be used to implement this feature on the GetTicket endpoint

• Sideload Proposal #153
• Second Proposal for Sideload  #154

Would love any feedback on how the sideload API is implemented here. There is more work that need to be done in order to support all of the options on the GetTicket api, so I will just put that guy out for now to get some feedback before going to far down that rabbit hole.

Personally i am in favor of the second proposal as i didn't need to rely on as much reflection. That said it came with the downside of some added dependencies.

@nukosuke Let me know what you think.

[abebars]

@tamccall any update on this? it's very useful to have this in the SDK.

[tamccall]

@abebars I have a proposal that has never been reviewed. Maybe look at my proposed implementation and give your comments/concerns?

#154