Oct 30th, 2016
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 4.27 KB | None | 0 0
  1. To:
  2. Subject: FAO Mod Balance // Wiki Requests
  4. Hi,
  6. Per the brief discussion on discord recently, I've compiled a list of requests for the web team. I appreciate that there are extremely limited resources available to implement this stuff, so I've tried to impose some sort of order on the following with the most important from our view at the top.
  8. # CORS Headers
  9. CORS (Cross-Origin Resource Sharing) headers are by far and away at the very top of our wishlist. If you guys aren't sure what they do there's a technical explanation at but the gist is that it allows us to access API resources from someone's browser. As it stands, the only way to access the RS APIs is to make a request server side which requires us on the wiki to use a 3rd-party service to make that request for us. The sites we use that provide these services are free, but are generally unstable and go down without warning. With CORS headers, it means we remove the middleman and can provide a much more stable service to users of the wiki.
  11. # Rate limits
  12. Right now, rate limits seem to be very poorly understood from those I've spoken to. For the website itself, they seem to be at around 5 pages per minute, but for the APIs it tends to be a guess of 1-2 seconds per request. I'd love to know exactly what the expected requests/minute are on the various APIs and if they're a little tough maybe request they be reduced. In essence, what should we be doing to be considered a good end-user of the APIs?
  14. # Batch requests
  15. This mainly applies to the exchange APIs but having this for hiscores and the bestiary would be an added bonus. One of the bots on the wiki looks up every item on the GE every day. Right now there are over 4000 items on the exchange which takes around 8 hours. If we could request data in batches of 10, 20 or 50 it would speed the process up hugely. It may even improve performance on your end depending on how performant batch database queries are.
  17. # Hiscores API
  18. The hiscores API is currently limited to looking up a single player at a time, with the only way of discovering players being the hiscores pages on the website itself. These pages are scraped each day by another bot in order to find the number of players with 99/120/maximum in each skill. However, the website seems to have some kind of DOS prevention which limits us to 5 requests per minute which is perfectly understandable. To avoid the issues this causes, I'd like to have an API equivalent of the hiscores pages with the same data.
  20. # GE Search API
  21. Every time a new item is released, we need to obtain it's item id before we can access it's exchange info. One way of doing this is by searching the item on the website and extracting its id from the URL which requires 3 separate pageloads. I believe another way is extracting them from the game cache, although I'm not too familar with that myself. To streamline this, I'd love to have an API we could use to search for items. For example, "Saradomin" might return results for brews, tt rewards, etc. It would also allow/improve other tools that might be used in IRC or discord.
  23. # GE Icons
  24. As I understand it, the current icons used in the exchange APIs are from the java version of the game. If these could be updated to use the NXT sprites, we could copy the images over and give ourselves a head start when new items are released. I have a feeling the images are also used on the Exchange pages on your website judging by the data in the API result, so no doubt it would benefit you too.
  26. # Name change tracking
  27. This one came from an admin on another fansite, but it's definitely something I could see being super useful. I imagine it being used for tracking tools where if someone changes their display name the tool can update the name and carry on as if nothing had happened rather than lose track until the user remembers to update the details. It's not something we'd have an immediate use for on the wiki, but in the interests of better API support, it's something I'd love to see.
  31. Hopefully the above aren't too much of a burden on the web team and if there's anything you'd like me to clarify feel free to drop me an email. I look forward to hearing from you soon.
  33. Best regards,
  34. Cqm (RSWiki Admin)/Oneiromancer (RSN)
Add Comment
Please, Sign In to add comment