Our sport feed provide multiple API levels when working with our data objects. The data received from the network is materialized as concrete instances of internal implementation classes. These instances, howevever, implement interfaces of different specificity level that represent:

• A specific sport: e.g. SoccerMatch, TennisMatch, etc…
• Sports that have two sides competing against each other, e.g IB2Match, IB2Event, IB2Record.
• Any sports, e.g. IBetMatch, IBetEvent, IBetRecord.

For example, for the same objects representing Soccer and Tennis matches, you have several options:

• Treat them specifically as SoccerMatch objects and TennisMatch objects. When using the SoccerMatch interface, you have access to methodss that are only specific to Soccer, such as checking if a match is neutral, getting the host or guest team, retrieving the number of recards for each team, etc… When using TennisMatch interface, you can use methods that are only specific to Tennis, such as checking if a match is mixed double, getting score of first set or second set, etc…

• Treat them as IB2Match, which contains methods common to all sports have two side playing against each other. In this API level, you will be provided with methods such as getting participant one or participant two, but there will not be a sport specific method. If you extract the event state (e.g. score of the match) at this level, you will only receive list of integer that you will have to intepret the numbers yourselves.

• Treat them as IBetMatch which is the most generic API. In this level, there is no distinction between a sport with two teams (Soccer, Tennis, etc..) and a sport with more teams playing (Horse Racing, Formula 1, etc…)

As you can see, the different API levels is suitable for different kind of application, and you can choose the one that is most convenient for you.

In term of class hierarchy, we organize our interfaces as following:

For matches

For events

For records

Note: The current structure is set for future additions of more functionalities, some API features mentioned here, for example checking the gender of a tennis match, e.g. mixed doubled or men single, or checking neutrality of a soccer match is not yet added at current release.

At time of writing, the most visible differences among different API levels are currently at the event states, the sport specific event states provide following API:

• SoccerEventState Provides methods to retrieve number of goals and red cards of the host and the guest team, and getting the match duration and match segment. More details
• TennisEventState Provides methods from the stats to retrieve the score for each set of the match, and whether the set is in tiebreak. More details
• BasketballEventState Provides methods from the stats to retrieve score for each quarter and half of the match. More details

The two side specific event states provide the following API:

• IB2EventState Provides method to retrieve the stats of each side of the event. For each of the stats, you can retrieve the scores as a list of integer. More details

The generic API for all sports provides the following API:

• IBetEventState Provides method to retrieve the stats of all players involving in the event. For each stats, you can retrieve the score as a list of integer. More details

Choosing API Level

To choose the API level you want to work with, you specify the match type when creating the view:

    FeedView<IBetMatch> generic = client.view(IBetMatch.class);

    FeedView<IBetMatch> genericTwoSide = client.view(IB2Match.class);

    FeedView<SoccerMatch> soccer = client.view(SoccerMatch.class);

    FeedView<TennisMatch> tennis = client.view(TennisMatch.class);

    FeedView<BasketballMatch> basketball = client.view(BasketballMatch.class);

The push mode handler attached to a view needs to be parameterized accordingly.