Endpoint Implementation Status

[theOehrly]

This issue is intended to track the status of the implementation of the various endpoints that need to be supported to achieve parity with Ergast.

Notes on the Implementation

• The implementation is currently limited to the JSON response format.
  The XML format and a graphical HTML representation in the browser do currently not exist.

• The implementation aims for mostly equivalent behaviour. Obvious bugs will be fixed instead of being reproduced.
  The behaviour may be different for rare edge cases if the amount of work to achieve parity is unreasonable or if
  said behaviour is considered a bug.

Notes on the Validation

• Validation is done through automated A/B comparison of hundreds of requests against Ergast and the new server.
• For a first validation pass, only the 2023 season is used to limit the amount of data that needs to be compared.
• All possible combinations of filters (e.g. driver, constructor, ...) are tested for each endpoint. For each combination
  of filters, a large number of filter values is tested over multiple requests.
• "http(s)://ergast.com/api" and "http(s)://api.jolpi.ca/ergast" are normalized to "SCHEMA://BASE" before comparison
• The order of elements in a JSON object ({}) is ignored. The JSON specification does not guarantee an order for
  elements in an object.

List of Endpoints and their Status (JSON)

Endpoint	Implementation Status	Validation Structure/Data	Notes	Ergast Documentation
/seasons	✅	✅/✅	#21	https://ergast.com/mrd/methods/seasons/
/, /races (schedule)	✅	❕ /✅	#47	https://ergast.com/mrd/methods/schedule/
/results (race)	✅	✅/✅	#20	https://ergast.com/mrd/methods/results/
/qualifying	✅	❌/✅	#7, #8, #9, #10	https://ergast.com/mrd/methods/qualifying/
/sprint	✅	❌/✅	#9	https://ergast.com/mrd/methods/sprint/
/driverStandings	✅	❕ /✅	#22, #23, #24, #25, #29	https://ergast.com/mrd/methods/standings/
/constructorStandings	✅	❕ /✅	#22, #23, #24, #29	https://ergast.com/mrd/methods/standings/
/drivers	✅	✅/✅	#14, #15	https://ergast.com/mrd/methods/drivers/
/constructors	✅	✅/✅	#14, #15	https://ergast.com/mrd/methods/constructors/
/circuits	✅	✅/✅	#14, #15	https://ergast.com/mrd/methods/circuits/
/status	✅	✅/✅	#14, #15	https://ergast.com/mrd/methods/status/
/laps	✅	✅/❌	#13	https://ergast.com/mrd/methods/laps/
/pitstops	✅	✅/✅		https://ergast.com/mrd/methods/pitstops/

Implementation: ✅ - Done, ⬛ - To be done
Validation: ✅ - Done, ⬛ - To be done, ❌ - Validation found problems, ❕ - Intentional Difference

[jolpica]

#13, #20 are both issues with data rather than implementation, so I think we can remove them from this.

#47, #29 and are only awaiting documentation.

I think #9 is the only currently open issue related to endpoint implementation issues?

[theOehrly]

Yes, correct. I was trying to convey this by splitting the validation column into "structure" and "data". Although, data is technically not implementation.