Hybrid doesn't contain actualStartTime, but match results does. 

If an application used the hybrid API and didn't care about match results it could ignore those fields.  If ignoring unused fields is a problem then the "event awards" interface is flawed.  With those the user isn't even given any guarantee about the format that they're in.  Besides, how do you know that an application would care about all the fields that are there now?

Scrapping "schedule" and "match results" in favor of a version of hybrid that contains a superset of their data wouldn't reduce what application could do.  And it would reduce by about 2/3 the amount of documentation needed for match-related data.  And this is the perfect time to remove redundant features since there has not yet been a stable release.  I definitely understand why this might not happen though. 

"Qualification" vs "qual" isn't a major issue but is more complicated than if it were "Qualification" at all times.  Whether the idea of a qualification match is represented by "qual" or "Qualifiction" is now context dependent.  It is avoidable complexity. 

Eric

On Sat, Feb 21, 2015 at 1:45 PM, Alex Herreid (FIRST) <aherreid@usfirst.org> wrote:
Is there something in particular you wanted that was on either schedule or match results but is not available in hybrid? When I look at the documentation from them, they seems to cover everything you could want from the combination of the two. We aren't going to remove the schedule and match results though- what if someone has an application that doesn't care about match results? With this structure, they aren't required to parse out the info they don't care about- they can just request what they do care about. We don't believe there is a reason to remove features.

Also, for "qual vs qualification", it shouldn't require any learning from the developer. Every endpoint (that takes a tournament level parameter) will accept "qual". However, we return "Qualification" as part of the response so that developers who are just interested in directly passing the data to a user and not needing to do anything special with it can have a more "formal" description. But there is no additional adjustment or learning for the developer- just use "qual" in all your requests and you will be all set.



_______________________________________________
FRC Event API Discussion

FRC Event API
https://usfirst.collab.net/sf/go/post4260
To cancel your subscription to this discussion, please e-mail frcapi-first_community_developers-unsubscribe@usfirst.collab.net