certainly not in its final form, but its a good foundation for getting the UI going.
currently this solution depends on mock data that is not included in the PR... technically none of the data is private, but i still felt weird about committing it.
the following routes are defined here:
GET /players
GET /players/:id
GET /players/:id/friends
GET /players/:id/games
I'm open to a different style, such as:
GET /players (with player id as query param)
GET /games (with player id as query param)
GET /friends (with player id as query param)
also open to adding an api prefix if we think that is useful.
note: some of the routes accept a steamID, but don't even actually use it yet. this is mainly a defect of the mock, since it only has data for certain players anyway. i didnt think it was worth it at this stage to make it more complex. Though it does factor in the actual steam ID when using the /players/:id route
19
certainly not in its final form, but its a good foundation for getting the UI going.
currently this solution depends on mock data that is not included in the PR... technically none of the data is private, but i still felt weird about committing it.
the following routes are defined here:
I'm open to a different style, such as:
also open to adding an
apiprefix if we think that is useful.i also tried to follow the project layout described here: https://github.com/golang-standards/project-layout though in some cases i wasn't sure if something should be in pkg vs internal vs cmd.
note: some of the routes accept a steamID, but don't even actually use it yet. this is mainly a defect of the mock, since it only has data for certain players anyway. i didnt think it was worth it at this stage to make it more complex. Though it does factor in the actual steam ID when using the /players/:id route