FIRST Community Developers/Discussion/FRC Event API/FRCAPI API design issues/List of Posts
 
Forum Topic - FRCAPI API design issues: (3 Items)
   
Update
eric rippey(deleted)
02/21/2015 9:22 PM
post4259
FRCAPI API design issues   
Why not include all of the data that exists in match schedule and in match results in the hybrid schedule and get rid of
 event schedule and match results?

It seems like a lot of options that could be orthogonal are mutually exclusive.

I know using "qual" some places and "Qualification" others is done on purpose, but it is a weird detail that users will 
all have to learn.
Alex Herreid (FIRST)
02/21/2015 9:45 PM
post4260
Re: FRCAPI API design issues   
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.
eric rippey(deleted)
02/23/2015 6:43 AM
post4272
Re: FRCAPI API design issues   
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
>
Attachment: HTML sf-attachment-mime4836 3.41 KB

Return