Closed irongut closed 3 years ago
Api method services will set the cache time but implement an adaptive cache that increases the time if there has been no change in the data for an extended period. e.g. Cache for 1 hour, if no changes in 3 days change cache expiry to 4 hours, if no changes after 7 days change cache expiry to 1 day; any update resets the cache time to 1 hour.
Knowing where the cache is in the current cycle will require a setting (platform specific) so better left to consuming code. Implement a minimum 1 hour cache time in the api service but allow consumer to increase it.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this issue will be closed in 30 days.
CommunityGoalsService.GetData
should check if its local cache covers the same requestDays
& maybe identity
before returning that data. Atm it does not.
Returns basic information about a commander from Inara like ranks, squadron, etc.
Property name | Description |
---|---|
searchName (string) | Commander's name. The input name provided is used in an exact match search against in-game commander names. If not found, it is then used to search Inara user names. If an exact match is not found, the first result of the search is returned. If no input name provided and personal API key is used, the profile of the current user is returned. |
Note: The 'commanderName' in the output is returned just when the 'searchName' and commander's in-game name exactly match (and is known). When there is no exact match, other possible names are returned in the 'otherNamesFound' list (up to 20 records).
Use Postman to research response when:
Data returned in events
(eventStatus
and eventData
) is the same for app key & user key.
Headers are different - with app key the header contains only eventStatus
, with user api key the header also contains data:
"header": {
"eventData": {
"userID": "151725",
"userName": "Irongut"
},
"eventStatus": 200
},
EDlib's InaraHeader
class does not include an eventData
property atm.
Including a commanderName property with a user api key doesn't change the response.
Like an exact match, headers are the only difference in response between a partial match with an app api key and a partial match with a user api key.
Partial match returns the most likely result and a list of other names found. Compared to an exact match:
events::eventStatus
is 202 instead of 200 - this may trip up error checking!events
: "eventStatusText": "Multiple results found."
commanderName
property is added to events::eventData
events::eventData
with a list of other matches "otherNamesFound": [
"IronGear",
"Irongrip",
"irongear_",
"Ironglove",
"Irongaming",
"Irongamer39",
"IronGhost24",
"Irongolem27",
"IronGremlin",
"IronGauntlet",
"Ironghost250",
"Irongunner1224",
"IronGAMER 76201",
"IronGlint713649"
]
The response with only a user api key and no searchName parameter is the same as an exact match with a user api key. (The data is for the user who matches the api key.)
Research with Postman.
01234
seraphin
Non-existent Cmdr with user api key:
{
"header": {
"eventData": {
"userID": "151725",
"userName": "Irongut"
},
"eventStatus": 200
},
"events": [
{
"eventStatus": 204,
"eventStatusText": "No results found."
}
]
}
Feature Request
Port INARA & Community Goals api from EliteALD. Allow new services in EDlib or consuming code to add new INARA api methods.
Add getCommanderProfile API to Demo app.too likely to be throttledRequires
Linked To
14 Make the library linker safe
56 Rework News & CG classification
60 Galactic Standings is not link safe
irongut/EliteALD#154 Complete transfer of code to EDlib