Git Product home page Git Product logo

riotapi-schema's Introduction

riotapi-schema

OpenAPI/Swagger Schema of the Riot Games API

Automatically generated daily from the Riot Games API Reference

Quirks/Hacks

The RG API Reference has many quirks and often has small errors or missing DTO specs. This project contains many hacks to deal with them which are worth knowing if you plan to use the generated schemas.

Missing DTOs for the latest version are stored in this JSON file.

Manual Overrides

If the portal documentation is wrong, DTOs can be manually overridden (see src/data/schemaOverrides.json).

"DTO borrowing"

If a DTO is missing from one endpoint, it may be possible to find it in another endpoint. Which endpoints can "borrow" from which other endpoints are listed in src/data/endpointSharedDtos.json. The file is updated as needed.

x-platforms-available

x-platforms-available is listed per path specifying which platforms are available. This only differs for the tournament-v4 and tournament-stub-v4 endpoints. Overrides are in src/data/endpointPlatformsAvailableOverrides.json.

tournament Endpoints (tournament-stub-v4 and tournament-v4)

These endpoints share all the same DTOs. However, they each have a copy of each DTO, so there is duplicate data. This also means if you are generating classes from these endpoints, there will be duplicate issues.

TODO Because these endpoints are closely connected, both of their DTOs are included under tournament-v4. This way there aren't duplicate copies of tournament DTOs. This behavior is specified by src/data/mockEndpoints.json.

Old Quirks

Quirks that may no longer be relevant.

league-v3's LeagueItemDTO and LeaguePositionDTO

This spec combines LeagueItemDTO and LeaguePositionDTO under the later name. This was a questionable choice because it results in fields with null values that users might expect to be filled in (when parsing a LeagueItemDTO). This behavior is removed for league-v4.

static-data's DTO type overrides.

Static data had some DTO fields that could be multiple different types as specified in their description. These were overridden using the dict in src/data/dtoDescriptionTypeOverrides.json Because the static data endpoints are removed, this is no longer an issue.

riotapi-schema's People

Contributors

apinat avatar blossomishymae avatar dependabot[bot] avatar guillerlt avatar johnedmonds avatar mingweisamuel avatar renja-g avatar themaxdavitt avatar thomasquinn avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar

Forkers

cnguy smartdigitalmarketplace riftnemesis r-trench apinat johnedmonds blossomishymae renja-g

riotapi-schema's Issues

Required Properties

Hey!

Thank you for this project as usual. I would like to talk about adding required model properties to two cases:

  1. Return Models (e.g. summoner-v4.SummonerDTO)
  2. Models that are parameters (e.g. tournament-v4.TournamentCodeParameters)

https://docs.swagger.io/spec.html

image

The reasoning is that it allows one to generate types using sw2dts, for example.

For the first case,
Do you think it would be wise to trust that all Riot League of Legend's model DTO's to always have the properties (required properties as defined by Swagger).

So for example, SummonerDTO

image

These fields should always exist, and so we can define them in the SwaggerSpec like so:

  summoner-v4.SummonerDTO:
    type: object
    title: SummonerDTO
    properties:
      profileIconId:
        type: integer
        format: int32
        x-type: int
        description: 'ID of the summoner icon associated with the summoner.'
      name:
        type: string
        x-type: string
        description: 'Summoner name.'
      puuid:
        type: string
        x-type: string
        description: 'Encrypted PUUID. Exact length of 78 characters.'
      summonerLevel:
        type: integer
        format: int64
        x-type: long
        description: 'Summoner level associated with the summoner.'
      revisionDate:
        type: integer
        format: int64
        x-type: long
        description: 'Date summoner was last modified specified as epoch milliseconds. The following events will update this timestamp: profile icon change, playing the tutorial or advanced tutorial, finishing a game, summoner name change'
      id:
        type: string
        x-type: string
        description: 'Encrypted summoner ID. Max length 63 characters.'
      accountId:
        type: string
        x-type: string
        description: 'Encrypted account ID. Max length 56 characters.'
    description: 'represents a summoner'
    required:
      - profileIconId
      - name
      - puuid
      - summonerLevel
      - revisionDate
      - id
      - accountId

The second case is a bit weird and really only applies to the models that are used as parameters, such as tournament-v4.TournamentCodeParameters.

image

In this case, I noticed that Riot doesn't really have a column to mention that something is optional, and instead places it in the description text. And so in my code, I just have something that checks for "optional" basically.

I've already coded the stuffs required to handle both cases, but it basically makes the above assumptions and is therefore hacky. Is it something safe enough to add? :O If not, I can just maintain it in a fork and keep testing.

V4 is missing

Title basically. All the v4 endpoints do not seem to be listed.

Error component is missing 'type'

in the components array in http://www.mingweisamuel.com/riotapi-schema/openapi-3.0.0.json, the first component schema Error, should have a type, alike other objects. It only contains properties.

Annotate enum types

From @RyadaProductions

name -> enum mappings

    // Cases for EndpointMethods.cs
    case 'queue':
      return 'RankedQueues';
    case 'champion':
    case 'championId':
      return 'Champion';
    case 'division':
      return 'Division';
    case 'tier':
      return 'Tier';
    // Cases for DataClasses.cs
    case 'Queue':
    case 'QueueId':
    case 'GameQueueConfigId':
      return 'Queues';
    case 'season':
    case 'Season':
    case 'SeasonId':
      return 'Seasons';
    case 'Champion':
    case 'ChampionId':
      return 'Champion';
    case 'GameType':
      return 'GameTypes';
    case 'GameMode':
      return 'GameModes';
    case 'MapId':
      return 'Maps';
    case 'Locale':
    case 'Locales':
      return 'Locale';
    case 'TeamId':
      return 'TeamId';
    case 'HighestAchievedSeasonTier':
      return 'Tier';

encryptedSummonerId description miss match

Hi, I have noticed, that the description of encryptedSummonerId parameters
is miss matching, not sure if there is more like this, but I was wondering where the right place would be to overwrite it.

[
  {
    "name": "encryptedSummonerId",
    "in": "path",
    "required": true,
    "schema": {
      "type": "string",
      "x-type": "string"
    },
    "description": "Summoner ID associated with the player"
  },
  {
    "name": "encryptedSummonerId",
    "in": "path",
    "required": true,
    "schema": {
      "type": "string",
      "x-type": "string"
    }
  },
  {
    "name": "encryptedSummonerId",
    "in": "path",
    "required": true,
    "schema": {
      "type": "string",
      "x-type": "string"
    },
    "description": "The ID of the summoner."
  },
  {
    "name": "encryptedSummonerId",
    "in": "path",
    "required": true,
    "schema": {
      "type": "string",
      "x-type": "string"
    },
    "description": "Summoner ID"
  }
]

Example:
https://developer.riotgames.com/apis#champion-mastery-v4/GET_getAllChampionMasteries
grafik

https://developer.riotgames.com/apis#spectator-v4/GET_getCurrentGameInfoBySummoner
grafik

Double `queueId` in `tft-match-v1.InfoDto`

Is it right that queueId is declared two times in the schema?
One is queueId and the other queue_id.
and one is optional and the other is not.

    tft-match-v1.InfoDto:
      type: object
      title: InfoDto
      properties:
        tft_game_type:
          type: string
          x-type: string
        tft_set_core_name:
          type: string
          x-type: string
        game_datetime:
          type: integer
          format: int64
          x-type: long
          description: 'Unix timestamp.'
        game_length:
          type: number
          format: float
          x-type: float
          description: 'Game length in seconds.'
        game_variation:
          type: string
          x-type: string
          description: 'Game variation key. Game variations documented in TFT static data.'
        game_version:
          type: string
          x-type: string
          description: 'Game client version.'
        participants:
          type: array
          items:
            $ref: '#/components/schemas/tft-match-v1.ParticipantDto'
            x-type: ParticipantDto
          x-type: 'List[ParticipantDto]'
+       queue_id:
          type: integer
          format: int32
          x-type: int
          description: 'Please refer to the League of Legends documentation.'
          x-enum: queue
        tft_set_number:
          type: integer
          format: int32
          x-type: int
          description: 'Teamfight Tactics set number.'
        endOfGameResult:
          type: string
        gameCreation:
          type: integer
          format: int64
        gameId:
          type: integer
          format: int64
        mapId:
          type: integer
          format: int64
+       queueId:
          type: integer
          format: int32
          x-type: int
          description: 'Please refer to the League of Legends documentation.'
          x-enum: queue
      required:
        - game_datetime
        - game_length
        - game_version
        - participants
        - queue_id
        - tft_set_number

Missing enums

We can include the fixed enums here, so we don't have to rely on Riot's JSONs being up-to-date.

Summoner-v4 ByPUUID has `name` field that seems to not exist anymore

Hey !
Just as a quick heads up, your schema still has the name property of ByPUUID on Summoner-V4 which seems to be removed in the official documentation and seems to not be returned by the API anymore either.

Riot API Docs:
image

riotapi-schema:
image

Currently it seems like fetching summoners is broken on Riven as a result, however thats something im not 100% sure on as im just learning rust.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.