RIOT API V3 - V1/2 endpoints deprecated on July 24th

[Colorfulstan]

RIOT released their V3 of the league api recently and there will be a deprecation period of 90 days starting soon until the old endpoints will not be working anymore.

https://discussion.developer.riotgames.com/articles/652/riot-games-api-v3.html

I will update my Fork for the endpoints I use and might also look into the general endpoint construction about half way through the deprecation period (around end of May I assume I will have the time to spare)

[EldoranDev]

I am currently in the middle of the prep for my finals, as soon as I can get time slots free i'll start working on this again and will port everything to v3 or integrate your changes (just open an pr).

[Colorfulstan]

90 days start now, endpoints v1/2 will be removed on July 24th https://discussion.developer.riotgames.com/articles/1053/v1v2-90-day-deprecation-period-has-begun.html

[EldoranDev]

@Colorfulstan I am currently freeing up timeslots and using them for LeagueJS i think V3 coverage should done with my "rework" of the code and I'll ping you and claudio in the next 1-3 weeks about reviewing my implementation

[Colorfulstan]

@EldoranDev It makes sense to include the V3 Endpoints within the rework and release the library as v1.0.0. with semver in mind. Started looking into the new endpoints, a lot of things change and in some regards will not be compatible out of the box to code that expects the previous API version (e.g. Match endpoint queue information).

So getting this done before the old endpoints deprecate might be the best course of action and gives a certain urgency so the project gets moving again ;)

Is there still a lot of architectural/design work to do, or is it just straight forward "timesink work" that needs to be done to make this happen?

[Colorfulstan]

I added the new endpoints to my Fork and migrated most of the methods since I need to work with the v3 endpoints asap, but I kind of doubt that it's suited for public use. Replaced the dynamic parameters with default-values, which might not have been the smartest idea in terms of development comfort.

[EldoranDev]

I just pushed my v3 implementation to the rework branch f09435ecc1678c6131c581ae62dccb2cd8841fd9. I still need to implement the caching.

Also I need to rewrite the documentation and add tests. But nevertheless I would ask you ( @Colorfulstan and @claudiowilson ) to maybe look over the reworked code and tell me if you like it or we should dismiss this idea and follow the old style of implementation.

[Colorfulstan]

Thanks, Ill try to have commented on it by monday.

[Colorfulstan]

@EldoranDev I think I commented on all the things, I assume you did get notifications for all the comments!?

In general I like splitting it up into smaller and more atomic parts. I think the architecture is fine so far and makes it more obvious which endpoint you will be using and to discover the methods related to that endpoint.

Summary:

• compatibility Layer might be unneccessary within the context that everyone who uses this lib will have to go over his code anyways to adapt for the V3 changes. Might consider using bluebird Promises to give more utility if someone needs/wants to use the original node-callback style (see http://bluebirdjs.com/docs/api/ascallback.html ). (Additionally bluebird Promises perform better then native JS Promises afaik) I personally prefer the Promise style so there would be less biased opinions required to make a more objective decision here ;)
• working internally with platformId should be default and variables named acchordingly to prevent confusion
• imo working with factory methods for the endpoint-urls would make it easier to read and maintain (+ with the current buildRequest method some endpoints will not work due to multiple REST parameters required). Region -> platform conversion can be done within the url-factory method of the Endpoint class wich can be used by the extending classes
• A Utility/Helper class should be added as is in the current release (containing region <-> platformId conversion and what might come up as handy helper. Methods might be added as static members to the main-class!?

[EldoranDev]

I'll look into your Comments, while short skimming your notes, i think i saw a lot of useful stuff. I have to learn for my Finals the next two days and then I'll go trough the comments.

[Colorfulstan]

@EldoranDev Any unpublished progress yet? I want to start working on it today, propably starting with adding factory functions for the endpoints and implementing the endpoints v3 (without caching).