Fixes the config.api_rate_limit_whitelist to have proper true values associated with the indexes after startup. This way, the index grab method of checking for a list entry (which the api_do_auth_check proc uses) works.
Removes BOREALIS I.
Implements HTTP POST requests, credit to Oisin100 from Yogstation13 for the ByondPOST.dll.
Implements the BOREALIS II datum and converts all calls to reroute to that.
Adds round logging to channel_announce channels.
This is another Update to the API that adds / changes:
Unified Naming of API Comands and API Functions. --> They are now called "API Commands" across all files and the DB
Moves API Related procs from world.dm to api.dm
Adds a proc to write the API commands to the db (so there is no need to manually maintain the list of API commands)
The name change needs to be done before the API is live.
No changelog because there is already a entry
This adds some useful functions to the API and redefines the way the params are checked.
API Versioning
Very important to be able to check from the client if the serverside API is still compatible with the client implementation
Refactored Params
Mark params as required / optional
Different types of params (string / integer / list / select / senderkey)
Name and description for params
API Function to get all the functions a specific ip/token combo is allowed to use
API Function to get details about a specific API function
he /world/Topic() API has been rewritten.
General function:
The API is initialized upon roundstart and generates a list of possible api requests from /code/datums/api.dm
Once a request is made the following checks are performed:
If a query parameter is set (the function that should be called)
If the ip is ratelimited (or rate-limit-whitelisted)
The query is authenticated against the db using ip, function and key
If these checks pass, it is validated that the api command exists
Then the api command is called, all supplied params are passed through
Each API function returns 1 no matter if it failed or succeded
Additional info is provided in the statuscode, response and data vars
The statuscode, response and data are send back to the caller (through list2params)
The data var is json encoded before sending it back
This is not backward compatible to the current API
Current API Clients need to be updated
