├── README.md ├── endpoints ├── connectivity.md ├── leaderboards.md ├── matches.md ├── players.md └── static_data.md └── feedback ├── MichaelNey.md ├── Nonsocial.md ├── aaron_to_do-20180629.md ├── aaronp.md ├── dstaszewski.md ├── hgrimm.md └── various_users.md /README.md: -------------------------------------------------------------------------------- 1 | # realm-api-docs 2 | This is the central collaboration point for HiRez Realm Royale Game API definition. The goal is to have one stop shopping for all ideas as the API is defined. 3 | 4 | The Endpoints directory is the initial stab at a few key endpoints to get the conversations started. It is probably not even close to where we'll end up. Various obvious endpoints aren't even mentioned here such as TestSession, Ping, GetPatchInfo, etc. We don't even have concept of getGods/Champions() nor getItems() yet. 5 | 6 | The Feedback directory contains a template (aaronp.md) I created that can be copied and renamed and your copy can be modified with your feedback. Your feedback will be visible to others. 7 | 8 | The API will evolve, but I want to 80/20 the first out with minimal risk of rework. Keep in mind that we have limited data available, and that data is only available once a match completes. 9 | 10 | The URL prefix for the url is: https://api.realmroyale.com/realmapi.svc 11 | 12 | Thank you all for your cooperation and assistance in this initiative. 13 | 14 | Aaron 15 | 16 | # Developer Guide 17 | [API Documentation](https://github.com/apugh/realm-api-proposal/wiki "Realm Royale API Documentation") 18 | -------------------------------------------------------------------------------- /endpoints/connectivity.md: -------------------------------------------------------------------------------- 1 | # Create Session 2 | **/createsession**[ResponseFormat]/{developerId}/{signature}/{timestamp} 3 | 4 | A required step to Authenticate the developerId/signature for further API use. 5 | - [ResponseFormat] = "json" or "xml" 6 | - {timestamp} is UTC time 7 | 8 | ```json 9 | { 10 | "session_id": "96AD8C1A916E461686240EE30D4E67EF", 11 | "timestamp": "6\/29\/2018 2:17:34 PM", 12 | "ret_msg": "Approved" 13 | } 14 | ``` 15 | 16 | 17 | # Test Session 18 | **/testsession**[ResponseFormat]/{developerId}/{signature}/{session}/{timestamp} 19 | 20 | A means of validating that a session is established. 21 | 22 | ```` 23 | returns a string ... 24 | Example: "This was a successful Test Session, blah, blah, blah ..." 25 | ```` 26 | 27 | 28 | # Ping 29 | **/ping**[ResponseFormat] 30 | 31 | A quick way of validating availabiltiy of the Hi-Rez API. 32 | 33 | ```` 34 | returns a string ... 35 | Example: "RealmAPI (ver 1.0.0.0) [PATCH - 0.3.225.0] - Ping successful. Server Date:6\/29\/2018 3:10:25 PM" 36 | ```` 37 | 38 | 39 | # Get Data Used 40 | **/getdataused**[ResponseFormat]/{developerId}/{signature}/{session}/{timestamp} 41 | 42 | Returns API Developer daily usage limits and the current status against those limits. 43 | 44 | ```json 45 | { 46 | "active_sessions": 3, 47 | "concurrent_sessions": 500, 48 | "request_daily_limit": 7500, 49 | "session_cap": 2000, 50 | "session_time_limit": 30, 51 | "total_requests_today": 1032, 52 | "total_sessions_today": 49, 53 | "ret_msg": null 54 | } 55 | ``` 56 | 57 | 58 | # Get Hi-Rez Server Status 59 | **/gethirezserverstatus**[ResponseFormat]/{developerId}/{signature}/{session}/{timestamp} 60 | 61 | Returns UP/DOWN status for the primary game/platform environments. Data is cached once a minute. 62 | 63 | ```json 64 | { 65 | "entry_datetime": "2018-06-29 14:31:35.315", 66 | "status": "UP", 67 | "version": "0.3.225.0", 68 | "limited_access": false, 69 | "ret_msg": null 70 | } 71 | ``` 72 | 73 | 74 | # Get Patch Info 75 | **/getpatchinfo**[ResponseFormat]/{developerId}/{signature}/{session}/{timestamp} 76 | 77 | Returns information about current deployed patch. Currently, this information only includes patch version. 78 | 79 | ```json 80 | { 81 | "version": "0.3.225.0", 82 | "version_id": 196833, 83 | "version_code": "OB3", 84 | "ret_msg": null 85 | } 86 | ``` 87 | -------------------------------------------------------------------------------- /endpoints/leaderboards.md: -------------------------------------------------------------------------------- 1 | # Get Leaderboard Details 2 | **getLeaderboard** {queue}/{ranking_criteria} 3 | 4 | Returns leaderboard information for a particular queue. 5 | - for duo and quad queues/modes the individual's placement results reflect their team/grouping; solo is self-explanatory 6 | - will limit results to the top 500 players (minimum 50 matches played per queue); we never like to expose weak/beginner players 7 | - players that select to be "private" will have their player_name and player_id values hidden 8 | - {ranking_criteria} can be: 1: team_wins, 2: team_average_placement (shown below), 3: individual_average_kills, 4. win_rate, possibly/probably others as desired 9 | - expect this data to be cached on an hourly basis because the query to acquire the data will be expensive; don't spam the calls 10 | 11 | ```js 12 | { 13 | "queue_id": 476, 14 | "queue": "Quad", 15 | "last_updated": "3\/18\/2018 5:14:27 PM", 16 | "leaderboard": [{ 17 | "rank": 1, 18 | "player_name": "BestPlayer", 19 | "player_id": 1242243, 20 | "matches": 234 21 | "team_wins": 15, 22 | "team_avg_placement": 5 23 | }, 24 | { 25 | "rank": 2, 26 | "player_name": "2ndBestPlayer", 27 | "player_id": 1242244, 28 | "matches": 423 29 | "team_wins": 16, 30 | "team_avg_placement": 5.1 31 | }], 32 | } 33 | 34 | ``` 35 | -------------------------------------------------------------------------------- /endpoints/matches.md: -------------------------------------------------------------------------------- 1 | # Get Match IDs by Queue 2 | **getMatchIDsByQueue** {queue}/{date}/{hour} 3 | 4 | Returns all matchID values for a queue for a particular timeframe. Similar to SMITE/Paladins 5 | 6 | ```js 7 | [ 8 | { 9 | "active_flag": "n", 10 | "match": 1793874 11 | } 12 | ] 13 | ``` 14 | 15 | # Get Match Details 16 | **getMatchDetails** {matchId} 17 | 18 | Returns end of match stats for a particular match. Intra-match stats are not available. 19 | - teams/id is only relevant for grouping within this match 20 | - deaths would be "1" or "0" 21 | - goal is to group by teams (not meaningful for the Solo queue), then players within the team 22 | - people have asked for listing a.) weapon owned at death (or end-of-match), and b.) weapon used to cause player's death ... this data isn't clearly available but I'm asking around about how to obtain it if possible. 23 | 24 | ```js 25 | { 26 | "match_id": 1793874, 27 | "region": "Europe", 28 | "queue_id": 476, 29 | "queue": "Quad", 30 | "duration_secs": 1805, 31 | "teams": [{ 32 | "id": 383773, 33 | "placement": 1, 34 | "players": [{ 35 | "name": "1stPlayer", 36 | "id": 3987123, 37 | "level": 22, 38 | "kills_player": 2, 39 | "kills_bot": 1, 40 | "assists": 1, 41 | "deaths", 1, 42 | "damage_player": 3361, 43 | "healing_player": 249.999985, 44 | "duration_secs": 1422, 45 | "damage_taken": 344, 46 | "killing_spree_max": 11, 47 | "dropped_out_flag": 0, 48 | "healing_player_self": 284, 49 | "damage_mitigated": 450, 50 | "class_name": "Warrior", 51 | "class_id": 2594, 52 | "damage_done_in_hand", 1231, 53 | "mines_wards_placed", 96, 54 | "earned_xp", 27100, 55 | "earned_tokens", 177 56 | }], 57 | }], 58 | } 59 | ``` 60 | -------------------------------------------------------------------------------- /endpoints/players.md: -------------------------------------------------------------------------------- 1 | # Get Player 2 | **getPlayer** [{playerId}|{playerName}]/{"hirez"}] | [{steamId}/{"steam"}] 3 | 4 | Returns basic player information 5 | 6 | ```js 7 | { 8 | "name": "RealmHero", 9 | "id": 123, 10 | "created_datetime": "3\/18\/2018 5:14:27 PM", 11 | "last_login_datetime": "6\/12\/2018 7:51:11 PM", 12 | "level": 22, 13 | "steam_id": 76561198199559770, 14 | "region": "Europe", 15 | "portal": "PSN", 16 | "portal_id": 9, 17 | "portal_userid": 6407668544069555067 18 | } 19 | ``` 20 | 21 | # Get Player ID By Name 22 | **getPlayerIdByName** {playerName} 23 | 24 | Returns list of player ID information where the Hi-Rez DB Player.Name value equals the playerName parameter. 25 | 26 | Typically this will be useful only for portal_id = 1 (PC players) and thus it would only be a list containing one node. 27 | 28 | Here is an example for playerName = 'ptddragon': 29 | 30 | ```js 31 | { 32 | "id": 5170981, 33 | "portal": "Hi-Rez", 34 | "portal_id": 1 35 | } 36 | ``` 37 | 38 | # Get Player IDs By GamerTag 39 | **getPlayerIDsByGamerTag** {portalId]/{gamerTag} 40 | 41 | Returns list of player ID information where the Hi-Rez DB Player.portal_id value equals the portalId parameter and the Hi-Rez DB Player.gamer_tag value equals the gamerTag parameter. 42 | 43 | Here is an example for portalId = 9 (PSN) and gamerTag = 'walrus2045': 44 | 45 | ```js 46 | { 47 | { 48 | "id":5242616, 49 | "portal":"PSN", 50 | "portal_id":9 51 | }, 52 | { 53 | "id":6917985, 54 | "portal":"PSN", 55 | "portal_id":9 56 | } 57 | } 58 | ``` 59 | 60 | # Get Player ID By Portal_UserId 61 | **GetPlayerIdByPortalUserId** {portalId]/{portalUserId} 62 | 63 | Returns list of player ID information where the Hi-Rez DB Player.portal_id value equals the portalId parameter and the Hi-Rez DB Player.portal_userid value equals the portalUserId parameter. 64 | 65 | Typically this would be a list containing only one node. 66 | 67 | Here is an example for portalId = 25 (Discord) and portalUserId = '23572087872421888': 68 | 69 | ```js 70 | { 71 | "id":6293586, 72 | "portal":"Discord", 73 | "portal_id":25 74 | } 75 | ``` 76 | 77 | # Get Player Stats 78 | **getPlayerStats** {playerId} 79 | 80 | Returns player stats for each [match_queue_id (solo 474, duo 475, quad 476), class (Warrior, Hunter, Mage, Engineer, Assassin)] combination. 81 | average_placement and placements are TBD based on query performance and will likely be that for only the past 30 days due to purging of the source table. 82 | 83 | ```js 84 | { 85 | "id": 123, 86 | "aggregate_stats": { 87 | "games_played": 2521, 88 | "kills_player": 1371, 89 | "kills_bot": 46, 90 | "killing_spree_max": 25, 91 | "deaths": 2479, 92 | "assists": 1214, 93 | "duration_secs": 5210000, 94 | "damage_player": 220190, 95 | "damage_done_in_hand": 210932, 96 | "damage_taken": 43790, 97 | "damage_mitigated": 5942, 98 | "healing_player": 249.999985, 99 | "healing_player_self": 6635, 100 | "wins": 8, 101 | "losses": 1519, 102 | "wards_mines_placed": 11098, 103 | "earned_xp": 1575850, 104 | "earned_tokens": 1442, 105 | "average_placement": 23, 106 | "placements": {"1": 8, "2": 7, "3": 13, "4": 12, "... 28": 0, "29": 3} 107 | }, 108 | "queue_class_stats": [{ 109 | "match_queue_name": "Solo", 110 | "match_queue_id": 474, 111 | "class_name": "Warrior", 112 | "class_id": 2594, 113 | "stats": { 114 | "games_played": 521, 115 | "kills_player": 371, 116 | "kills_bot": 6, 117 | "killing_spree_max": 5, 118 | "deaths": 479, 119 | "assists": 214, 120 | "duration_secs": 52100, 121 | "damage_player": 22019, 122 | "damage_done_in_hand": 21832, 123 | "damage_taken": 4379, 124 | "damage_mitigated": 942, 125 | "healing_player": 249.999985, 126 | "healing_player_self": 663, 127 | "wins": 2, 128 | "losses": 519, 129 | "wards_mines_placed": 1098, 130 | "earned_xp": 157850, 131 | "earned_tokens": 442, 132 | "average_placement": 17, 133 | "placements": {"1": 2, "2": 4, "3": 3, "4": 3, "... 26": 0, "27": 1} 134 | } 135 | }, 136 | { 137 | "match_queue_name": "Duo", 138 | "match_queue_id": 475, 139 | "class_name": "Warrior", 140 | "class_id": 2594, 141 | "stats": { 142 | "games_played": 521, 143 | "kills_player": 371, 144 | "kills_bot": 6, 145 | "killing_spree_max": 5, 146 | "deaths": 479, 147 | "assists": 214, 148 | "duration_secs": 52100, 149 | "damage_player": 22019, 150 | "damage_done_in_hand": 21423, 151 | "damage_taken": 4379, 152 | "damage_mitigated": 942, 153 | "healing_player": 249.999985, 154 | "healing_player_self": 663, 155 | "wins": 2, 156 | "losses": 519, 157 | "wards_mines_placed": 1098, 158 | "earned_xp": 157850, 159 | "earned_tokens": 442, 160 | "average_placement": 17, 161 | "placements": {"1": 2, "2": 4, "3": 3, "4": 3, "... 26": 0, "27": 1} 162 | } 163 | }] 164 | } 165 | ``` 166 | 167 | # Get Player Match History 168 | **getPlayerMatchHistory** {playerId} 169 | 170 | Returns high level data regarding matches played in the past 30 days. Limited to the 50 most recent matches. 171 | 172 | ```js 173 | { 174 | "name": "RealmHero", 175 | "id": 123, 176 | "matches": [{ 177 | "match_id": 526153, 178 | "match_datetime": "6\/14\/2018 5:14:27 PM", 179 | "match_duration_secs": 1243, 180 | "map_game": "LIVE Royale Map", 181 | "match_queue_name": "Duo", 182 | "match_queue_id": 475, 183 | "class_name": "Mage", 184 | "class_id": 2285, 185 | "team_id": 123828, 186 | "region": "Brazil", 187 | "gold": 0, 188 | "kills": 1, 189 | "creeps": 1, 190 | "assists": 0, 191 | "deaths": 1, 192 | "time_in_match_minutes": 8, 193 | "time_in_match_secs": 513, 194 | "placement": 17, 195 | "player_id": 0, 196 | "damage": 2295, 197 | "damage_taken": 1949, 198 | "healing_player": 325 199 | "healing_player_self": 308, 200 | "healing_bot": 0, 201 | "killing_spree_max": 1, 202 | "damage_mitigated": 1500, 203 | "damage_done_in_hand": 300, 204 | "wards_mines_placed": 94 205 | }] 206 | } 207 | ``` 208 | 209 | # Get Player Status 210 | **getPlayerStatus** {playerId} 211 | 212 | Returns player online/offline status. 213 | 214 | ```js 215 | { 216 | "match_id": 1181882, 217 | "match_queue_id": 475, 218 | "personal_status_message": null, 219 | "status_id": 3, 220 | "status": "In Game", 221 | "ret_msg": null 222 | } 223 | ``` 224 | 225 | # Search Players 226 | **searchPlayers** {playerName} 227 | 228 | Returns up to 500 players with playerName starting with parameter provided. 229 | 230 | ```js 231 | [ 232 | {"id":53198, 233 | "name":"EonicBoom", 234 | "ret_msg":null, 235 | "steam_id":76561198132255826 236 | }, 237 | {"id":1741198, 238 | "name":"Eonic", 239 | "ret_msg":null, 240 | "steam_id":76561198117389412 241 | } 242 | ] 243 | ``` 244 | 245 | -------------------------------------------------------------------------------- /endpoints/static_data.md: -------------------------------------------------------------------------------- 1 | # Get Talents 2 | **getTalents** {lang} 3 | 4 | Returns all Talents 5 | 6 | ```js 7 | [ 8 | { 9 | "category_name":"Talent Vendor Assassin", 10 | "item_id":23770, 11 | "loot_table_item_id":49323, 12 | "ret_msg":null, 13 | "talent_description":"Forge abilities for 20 less shards.", 14 | "talent_name":"Ability Efficiency" 15 | }, 16 | { 17 | "category_name":"Talent Vendor Assassin", 18 | "item_id":23776, 19 | "loot_table_item_id":49354, 20 | "ret_msg":null, 21 | "talent_description":"Forge Potions 20s faster.", 22 | "talent_name":"Alchemy" 23 | }, 24 | { 25 | "category_name":"Talent Vendor Assassin", 26 | "item_id":23801, 27 | "loot_table_item_id":49336, 28 | "ret_msg":null, 29 | "talent_description":"Heirloom Rifles deal 40% increased damage within 3s of using a Movement ability.", 30 | "talent_name":"Ancient Power" 31 | } 32 | ] 33 | ``` 34 | -------------------------------------------------------------------------------- /feedback/MichaelNey.md: -------------------------------------------------------------------------------- 1 | # Realm Royale Endpoint Feedback 2 | **specifically related to Realm Royale** 3 | 4 | - With the player endpoints, I'm sure other developers, and even players would love to see Class specific data (Warrior, Engineer, Assassin, Hunter, Mage) - While maintaing overall player statistics. This could include typical 'getPlayerStats' information, but possibly under a new endpoint such as 'getPlayerClassStats{playerID | playerName, classID | className}' to not slow query performance for 'getPlayerStats' endpoint. [AP 2018-06-15]: except for average_placement & placements, the rest of the data is spoon fed to me for a player's (match_queue, class) combination. I'm not seeing data that says "Warrior, Engineer, Assassin, Hunter, Mage", but rather "MaleTank, FemaleDamage, FemaleSupport, MaleUtility, MaleFlank". Right now I'm guessing these 5 classifications are really the same thing in some way. For now I'll just denormalize the data that is now "match_queue" into "player_details". See the updated getPlayerStats() endpoint. 5 | 6 | - For the basic 'getPlayer' API Endpoint, I'd love to see a field for SteamID if they made an account through Steam, and if not it could just be set to null. This would be very relevant for developers who are making Data Visualization projects based off of Realm Royale statistics, and a consumer using the service could lay claim to a certain user by authenticating via Steam - To be confirmed by the SteamID field in the getPlayer query. [AP 2018-06-15]: I can do that. Would always be Null if the player's Privacy is turned on. 7 | 8 | - If class specific data is ever implemented to a player data endpoint I think it would be beneficial for those doing statistical analysis to see total value of 'X' effect each ability that class has. 9 | 10 | - The 'average_placement' and 'placements' being TBD due to query performance is understandable. Perhaps you could just track placement count for top 5 or top 10, and calculate 'average_placement' after every game instead of keeping track of it via the 'placements' field (Which I assume is what would be done if it is said to be detrimental to query performance). [AP 2018-06-15]: I'm certain I'll have to coordinate with the Dev team for an optimal solution, yes. 11 | 12 | What could be done is assigning each placement a static value or a score. '1st place: 1 point, 2nd place: 2 points, 3rd place: 3 points`, and after every game add the placement value of that match to a 'total_placement' field in player stats then divide that by 'games_played' to get the average placement. This would rid the need to track each individual placement by only tracking the one single value, thus reducing risk for query performance issues. 13 | 14 | Sadly this would take away some specific information that may be wanted by developers, but would still allow an `average_placement` field that would be accurate up to the Players first match (Which is what I would personally prefer rather than only for the past 30 days). Could also be used to save Engineers valuable time from being forced to work on a method to optimize the query performance! 15 | -------------------------------------------------------------------------------- /feedback/Nonsocial.md: -------------------------------------------------------------------------------- 1 | # API Architecture Feedback 2 | 3 | ## Remove / rework the ``GetDataUsed ()`` Method 4 | It's like the stachu540 [said](https://github.com/apugh/realm-api-proposal/blob/master/feedback/dstaszewski.md#api-architecture-feedback)... 5 | - As it will be removed, return the ``Header`` containing the info about the data used for every method request: 6 | 7 | ``stachu540`` example: 8 | ```yaml 9 | Headers: 10 | X-Rate-Limit: 7500 11 | X-Rate-Limit-Remaining: 7499 # after first query will responde one less than X-Rate-Limit 12 | X-Rate-Limit-Reset: 1529091932 # unix timestamp in UTC (2018-06-15T19:45:32+00:00) 13 | ``` 14 | 15 | - It can be something like too: 16 | 17 | This Headers will just be returned when used ``CreateSession ()`` 18 | ```yaml 19 | Headers: 20 | Request-Limit-Daily: 7500 21 | Session-Cap: 500 22 | Session-Concurrent-Limit: 50 23 | Session-Time-Limit: 15 24 | ``` 25 | 26 | This Headers will be returned for every method request 27 | ```yaml 28 | Headers: 29 | Request-Requests-Today: 51 30 | Request-Sessions-Today: 29 31 | Session-Active: 9 32 | ``` 33 | 34 | - If it be refused, remove the ``GetDataUsed ()`` being counted as Request (Actually, every ``GetDataUsed ()`` request will decrease the requests remaining by one) 35 | 36 | ## Remove the [ResponseFormat] from the ``/Ping[ResponseFormat]`` Method 37 | - Why we need to Request as JSON, if what will be returned is Text Plain, not JSON? (I know that ``/PingXML`` will return a XML-like, but...) 38 | 39 | **Requesting as JSON**: http://api.realmroyale.com/realmapi.svc/PingJSON 40 | ``` 41 | "RealmAPI (ver 1.0.0.0) [PATCH - 0.3.225.0] - Ping successful. Server Date:6/28/2018 1:26:12 AM" 42 | ``` 43 | 44 | **Requesting as XML**: http://api.realmroyale.com/realmapi.svc/PingXML 45 | ```xml 46 | RealmAPI (ver 1.0.0.0) [PATCH - 0.3.225.0] - Ping successful. Server Date:6/30/2018 9:43:32 PM" 47 | ``` 48 | 49 | ## Move the Official Documentation API to Github 50 | - One repository for each API endpoint (Smite, Paladins and Realm Royale) 51 | - The repository will contains: The ReadMe.md with contain an intro / short description about the API and a "shortcut" for the Wiki, and code samples. 52 | - All Documentation will be found on the Wiki. (I can help here, if requested / needed!) 53 | 54 | ## A full list about the ret_msg messages 55 | I've wrote the ret_msg message that I've catched [here](https://github.com/apugh/realm-api-proposal/wiki/Getting-Started#ret_msg), but probably it's not all. 56 | 57 | # Realm Royale Endpoint Feedback 58 | 59 | ## Remove the XML support. 60 | I saw no one using XML, JSON is better... 61 | 62 | If it's accepted, rework all methods to: 63 | - ``/CreateSession/{devID}/{signature}/{timestamp}`` 64 | - ``/GetDataUsed/{devID}/{signature}/{session_Id}/{timestamp}`` 65 | - ``/GetHiRezServerStatus/{devID}/{signature}/{session}/{timestamp}`` 66 | - ``/GetPatchInfo/{devID}/{signature}/{session}/{timestamp}`` 67 | - ``/Ping`` 68 | - ``/TestSession/{devId}/{signature}/{session_id}/{timestamp}`` 69 | - ``/GetLeaderboard/{devId}/{signature}/{session_id}/{timestamp}/{queue}/{ranking_criteria}`` 70 | - ``/GetMatchDetails/{devId}/{signature}/{session_id}/{timestamp}/{matchId}`` 71 | - ``/GetMatchIDsByQueue/{devId}/{signature}/{session_id}/{timestamp}/{queue}/{date}/{hour}`` 72 | - ``/GetPlayer/{devId}/{signature}/{session_id}/{timestamp}/{player}/{platform}`` 73 | - ``/GetPlayerMatchHistory/{devId}/{signature}/{session_id}/{timestamp}/{player}`` 74 | - ``/GetPlayerStats/{devId}/{signature}/{session_id}/{timestamp}/{player}`` 75 | - ``/GetPlayerStatus/{devId}/{signature}/{session_id}/{timestamp}/{player}`` 76 | 77 | ## Remove the duplicate / "useless" data: 78 | - Have a lot information that really don't need to be returned (Extra data)... And we can filter it now! (Ofc there more extra data, but we can start here) 79 | 80 | ```diff 81 | + { "name": "RealmHero", 82 | + "id": 123, 83 | + "matches": [{ 84 | + "match_id": 526153, 85 | + "match_datetime": "6\/14\/2018 5:14:27 PM", 86 | + "match_duration_secs": 1243, 87 | + "map_game": "LIVE Royale Map", 88 | - "match_queue_name": "Duo", 89 | + "match_queue_id": 475, 90 | - "class_name": "Mage", 91 | + "class_id": 2285, 92 | + "team_id": 123828, 93 | + "region": "Brazil"}] 94 | + } 95 | 96 | ##### Full-explaination: 97 | - Remove "queue" / queue name from GetLeaderboard () 98 | P.S: How it returned as array, maybe it can be removed too: "rank" (The array index / array length can be used to determine who is the rank 1, 2, 3, etc ....) 99 | 100 | - Remove "queue" / queue name from GetMatchDetails () 101 | 102 | - Remove "match_queue_name", "class_name" from GetPlayerMatchHistory () 103 | 104 | - Remove "match_queue_name", "class_name" from GetPlayerStats () 105 | 106 | - "status" from GetPlayerStatus () 107 | ``` 108 | -------------------------------------------------------------------------------- /feedback/aaron_to_do-20180629.md: -------------------------------------------------------------------------------- 1 | 2 | *Top Priorities* 3 | - Work w/Development to ensure Aggregate Wins (and other Aggregate Data) is correct 4 | [2018-07-09 Update]: Dev Team has identified a fix. Hopefully fix makes it to live by July 13 (goal). 5 | 6 | - Consider Items/Weapons in an endpoint (work with development team) 7 | [2018-09-09 Update]: Still TBD. 8 | 9 | *Secondary Priorities* 10 | - Continue updating Documentation 11 | -------------------------------------------------------------------------------- /feedback/aaronp.md: -------------------------------------------------------------------------------- 1 | 2 | # API Architecture Feedback 3 | **general comments** 4 | 5 | - What is going on with Rate Limits? blah, blah, 6 | - Can't we move away from URL parameters to Request Body data, blah, blah, blah 7 | - Does anyone actual use XML vs JSON anyway, blah, blah, blah, blah, blah 8 | 9 | - Sample edit showing pull request. 10 | 11 | 12 | 13 | # Realm Royale Endpoint Feedback 14 | **specifically related to Realm Royale** 15 | 16 | - How can you not know which Weapon was used to kill someone? blah, blah 17 | - getMatchIDsByQueue() seems clumsy! A better way is ... blah, blah, blah 18 | -------------------------------------------------------------------------------- /feedback/dstaszewski.md: -------------------------------------------------------------------------------- 1 | # API Architecture Feedback 2 | 3 | Presented `curl` sample is a example revisiting API. The changes will be a different than it can be assumed. 4 | 5 | Also i made up a [sample API code](https://app.swaggerhub.com/apis/stachu540/Smite/v2) (partly) using [OAS3](https://swagger.io/docs/specification/about/). Those samples it is a proposial to changes. Hi-Rez Studios will change it for their purpose. 6 | 7 | - _What is going on with Rate Limits?_ 8 | 9 | Rate limits will prevents to flooding data and blocking user if he reacing the limits. Currently you are use: `/getdataused` 10 | which are shows our limits. But if you are sending those request your daily limit will be decreased to one less query limits remain. 11 | Mostly API developers using rate limits inside the headers. 12 | Example response (Dayli limit): 13 | ```yaml 14 | Headers: 15 | X-Rate-Limit: 7500 16 | X-Rate-Limit-Remaining: 7499 # after first query will responde one less than X-Rate-Limit 17 | X-Rate-Limit-Reset: 1529091932 # unix timestamp in UTC (2018-06-15T19:45:32+00:00) 18 | ``` 19 | 20 | - _Can't we move away from URL parameters to Request Body data, blah, blah, blah:_ 21 | 22 | _Yes and No_. 23 | 24 | **No** if we want creating other queries than GET method. Request Body doesn't work for GET method. Your API is mainly using GET request. 25 | 26 | **Yes** if we want to stick into the GET request method. So we will use request into the parameters like this (only examples): 27 | - Search Teams (SMITE): 28 | ```sh 29 | curl -H "X-API-Key: $(echo -n "{dev_id}:{session_id}:{auth_key}" | md5sum | cut -d"-" -f1 -)" https://api.smitegame.com/pc/teams?name=dignitas 30 | ``` 31 | 32 | - Players: 33 | ```sh 34 | curl -H "X-API-Key: $(echo -n "{dev_id}:{session_id}:{auth_key}" | md5sum | cut -d"-" -f1 -)" https://api.paladins.com/pc/players?username=creativs2 35 | ``` 36 | - _Does anyone actual use XML vs JSON anyway, blah, blah, blah, blah, blah_ 37 | 38 | XML is not much popular Response Body. Many programmers using a JSON response. We can compare [JSON vs XML](https://www.w3schools.com/js/js_json_xml.asp) on those site. In short, JSON is better readable object than XML. 39 | For example in Java i use [Jackson](https://github.com/FasterXML/jackson-databind) to parsing response into the [POJO](https://en.wikipedia.org/wiki/Plain_old_Java_object). 40 | -------------------------------------------------------------------------------- /feedback/hgrimm.md: -------------------------------------------------------------------------------- 1 | 2 | # Realm Royale Endpoint Feedback 3 | **specifically related to Realm Royale** 4 | 5 | * I'd suggest adding an endpoint for a players' match history similar to getMatchHistory (params: playerName) in SMITE/Paladins API. In case the calls for average_placement and placements in getPlayerStats are too performance heavy, you could relocate the single placements into the matches returned by the suggested getMatchHistory endpoint so the developer can estimate the averages by himself. [AP: 2018-06-15]: Will definitely have getMatchHistory() ... I'll try to sketch it out this afternoon. Good point on the actual placements since no special calculations will be needed for them for each particular match. 6 | 7 | * A little neat, but yet unfundamental stat to be pulled would be the death position of a player, in case this data is available. =) [AP: 2018-06-15]: I think we've been calling that "placement" unless I'm missing something ..? 8 | 9 | * Additionally, to reduce the transfer of unneccessary data (and with that, higher bandwidth), a players endpoint for his teams' performance in a particular match would be extremely helpful (e.g. getPlayerTeamDetails, params: matchID). This endpoint will return the data block for the players' team only, excluding the stats for potential 49 other Duos or 24+ Squads. 10 | 11 | Why this would help: (estimations chosen freely) 12 | - 90% of people are interested in players performance only (getMatchHistory) 13 | - Assuming a user would also be interested in the players' team performance, the current endpoints would require me pulling the whole match block and excluding all other teams from my end evaluation. To prevent this, a new endpoint of getPlayerTeamDetails by a matchID would drastically reduce the unused output (unimportant for a single situation, but influential on 1000+ daily pulls by each dev). 14 | - Developers that would want to analyze all teams will still have the getMatchDetails endpoint as an easy solution. [AP: 2018-06-15]: How about just an optional teamId parameter with getMatchDetails()? 15 | 16 | 17 | UPDATE 15. June: 18 | 19 | - An endpoint or option for a users class performance would be awesome for the early release of the API (like getPlayerStats desc. states: "If desired, that data can be broken out separately.") [AP: 2018-06-15]: getPlayerStats() will do this. 20 | 21 | - Since Ranks are already implemented in the game, I hope that these could be integrated into the getPlayer endpoint. =) 22 | 23 | - I agree with MichaelNay that a field for the players STEAM_ID would be beneficial and would love to see that implemented (if possible). =) [AP: 2018-06-15]: planning to do this in getPlayer(). 24 | 25 | - Beside the won matches, could getLeaderboard also return the amount of total matches? [AP: 2018-06-15]: yes, done 26 | -------------------------------------------------------------------------------- /feedback/various_users.md: -------------------------------------------------------------------------------- 1 | 2 | # Realm Royale API Feedback (multiple contributors) 3 | **Eric SmiteGuru** 4 | 5 | - get player stats call - break out by Profile (MaleTank, FemaleDamage,..) since it's what makes the game unique from other BRs and more classes are planned and it would be a shame to lose that granularity of data when it can just be combined to get the summary per queue by the developer like it is on Smite and Paladins atm. [AP: 2018-06-15]: Yes, getPlayerStats() will return aggregate and (match_queue, class) detailed breakdowns of stats. 6 | 7 | - Match Details call - would deaths not increment for the times someone gets downed or turned into a chicken? And do you know what this field is for: dropped_out_flag? [AP: 2018-06-15]: Good questions ... will check w/Dev 8 | 9 | - Would it be possible to add the region that the match took place into the top level match object where the match_id and queue stuff is? [AP: 2018-06-15]: Yes. 10 | 11 | **CSpraggs** 12 | 13 | - Leaderboards: Add average kill count? If I understand correctly the highest ranks are based on kill count too. [AP: 2018-06-15]: Yes, will add it. 14 | 15 | - Players: As granular as possible so splitting up average_placement is preferred over grouping them. [AP: 2018-06-15]: Yes, getPlayerStats() will return aggregate and (match_queue, class) detailed breakdowns of stats. 16 | 17 | **Negativitet** 18 | - Could getPlayerMatchHistory() be built to handle up to some level of multiple playerId inputs? To simplify for us that want to work with multiple players at the same time? Getting the result for 25 playerIds at once will be less intense on databases than fetching one result x 25 times. [AP: 2018-07-10]: It will be possible. I will give it some thought as it would require some rework that is lower on my priority list (across ALL projects beyond APIs) at the moment. 19 | 20 | - getPlayerMatchHistory() could benefit from **optional** input parameter, something like "last fetch timestamp" so that you don't re-fetch results you've already gathered. Like so: getPlayerMatchHistory(12345,'2018-07-10 11:38:00') and then you get results for 12345 that are saved later than 2018-07-10 11:38:00. [AP: 2018-07-10]: Good idea. I threw together an entirely new endpoint called getPlayerMatchHistoryAfterDatetime() ... it takes a startDatetime parameter immediately before the playerId parameter. The startDatetime format must be precisely yyyyMMddHHmmss ... I'm yet to advertise it with the other endpoints because I haven't tested it enough and won't have time today to do so ... but you can take a look if you like. I think it will work :-) returning data of the exact format as getPlayerMatchHistory(). 21 | Negativitet: Works fine! Might be a side note to point out that if you are using your last match match_datetime as the base to fetch new matches from, you have to add the time_in_match_secs on top of that time +1 second for it to show an empty result. Also just to make sure no one gets confused, add in the description of the endpoint when created in the docs that for the input data you have to concatenate the yyyyMMddHHmmss and playerId into one (yyyyMMddHHmmss12345). 22 | --------------------------------------------------------------------------------