Not clear which methods will make API requests and which won't

[carols10cents]

With the new linked resources methods, it's not always clear when you have a CleverObject and call methods on it which methods will be doing HTTP calls to the Clever API and which will not.

This is important since we want to minimize the amount of network traffic and avoid it if we don't need it.

Our use case is that, when we do an import from Clever, we create all the objects and then go back and associate them once they exist. Previously, calling, for example, section.students would return the array of student ids associated with that section-- which is all we need when we're associating the two anyway. In the new version of the gem, this fires API requests to get all the data for the students.

We're currently working around this by changing these types of places from section.students to section[:students]. This is kind of confusing, though, since we can ask for other attributes on section using methods and that doesn't make an API call, like section.grade. This requires vigilance to remember what is an attribute and what is an association.

To further muddy the waters, calling event.object seems like it WOULD make an API call, but it does not, as far as I can tell.

I'm not sure exactly what the right solution here is. Maybe define methods for the associated resources that are, e.g., section.student_ids that wouldn't have the name collision that #students and [:students] has. Maybe making the API calling methods have a name like fetch_students. Or close this issue if this doesn't seem like a problem to you, I would also accept that response :)

[osdiab]

I think this is a valid concern and I'll think about a good way to reconcile this, give me a bit as I have a bit of stuff to catch up on after being away for a year from this project :)

If we do decide to tackle this then it would very likely be a breaking change—just a friendly warning.

[carols10cents]

If we do decide to tackle this then it would very likely be a breaking change—just a friendly warning.

That's no problem here; I totally understand the tradeoffs between improvements and maintaining backwards compatibility, and I usually come down on the side of improvements :)