Unofficial APIs
github.com
github.com
And then, like, three days after we started the journey, someone had not only beat us to the punch, they had done so at a professional level. I don't remember which site it was, but not only did it work perfectly, it didn't require the "crowd sourced" solution to mapping out pokemon that we were counting on. The developer/s had somehow figured out how to just yank all pokemon locations. And on top of that the app was functional, gorgeous, even had its own URL (we were still in the "all our apps are laughinggiraffe.herokuapp.com domains" phase).
All in all, great experience. A nice fresh slap in the face to how much work we had ahead of us, and good fun had anyway.
I noticed that one of the more popular SF pokmeon go mapping websites was using a simple REST API. You gave it a coordinate, and it would spit out locations for all pokemon within a mile radius or so. I created a background python task on my computer that would hit this API every 2 minutes with my apartment's location, plus like a mile range around it.
If it found any rare pokemon (Gyrados, Dragonite, etc.) the python program sent a message to a specific slack channel that I set up. It was an easy way for me to get push notifications on my phone when something spawned around me. From there, I would high tail it on my bike and catch the pokemon. I still have this Pokemon channel at my work Slack instance haha.
It was amazing. My pokedex filled up so quick. This approach only worked for about 3 weeks until Niantic majorly cracked down on their API, which rendered all the API scrappers obsolete. But that period was by far the most fun I had with Pokemon GO. I whipped that program up in like 3 hours on a Saturday and it was the only time in my life where I've felt like a l33t hacker, even though I was doing some very basic REST API operations. The actually impressive thing was the mapping website that was scrapping the actual Niantic API.
The number of fake accounts was a function of how large of an area you wanted to cover and how often you wanted it to update.
The technology behind those tiles wasn't really sophisticated back then -- a few oversized and replicated PostgreSQL servers with PostGIS and the OSM data loaded and synchronized frequently with a few materialized views on top, and a bunch of servers painting tiles with Mapnik using them as a source (there are a few options that started to prove to be more efficient at the time, but that's what we decided to go on then for other reasons), with a few layers of caching on the front. Tile rendering times for cache misses weren't really good depending on the complexity of the requested tile, given most stuff wasn't prerendered, but once things got cached and since most popular maps were localized to specific regions that got quickly cached, this worked pretty well after the first visitor had came.
But then... Pokemon Go and your bazillion maps came with the worst scale test for our design you could ever think of: a volume of tile requests a few levels of magnitude higher than usual, of locations from the half of the world playing Pokemon Go back then, zooming to _their streets_ (which were randomly distributed all over the world and therefore most probably uncached at that zoom level) to try and find their closest Charmanders.
Needless to say, those were some few nice days of firefighting and playing whack-a-mole replicating databases, adjusting caches, banning requests from the worst offenders and, at some of the worst points, everything that included the word "poke" on their domain.
It's down now but here's the archive: https://web.archive.org/web/20170308154111/www.instapokego.c...
I've been hit with some burnout recently, and this is the kind of inspiration I need. Small, fun, short term project to get some juices flowing, as opposed to forcing myself to work on personal projects I currently don't have passion for, but feel I need to work on out of some weird sense of obligation.
Thanks, this is actually a really great help.
[site:github.com "unofficial" AND "API"]
Or click here:
https://www.google.com/search?q=site:github.com+%22unofficia...
https://github.com/RIAEvangelist/node-dominos-pizza-api and https://pypi.org/project/dominos/
The package works pretty well in my experience. Something that I found mildly interesting though is that Dominos has not changed their API since I implemented it. Since this is unsupported (and honestly, probably frowned upon), I was expecting this to break early/often; thankfully, that has not been the case.
It'd be cool to link up a script that takes a new task in Omnifocus under the right tag, and push a template into Notion for the note taking, and sync a link back into the notes field of Omnifocus for quick access.
Bad idea? Likely.
Worth the squeeze? YMMV.
My goal is to open source this, and allow anyone to contribute new / update existing drivers. Would there be interest in something like this?
I tried writing a CLI tool for ordering Chipotle, but I ran into some dynamically generated headers, that made it near impossible to authenticate. In the end, I gave up.
Would love to see more examples and see how issues like this can be handled!
I've used jadx once before to decompile a steamship line app, but it was just curiosity with no end goal in mind. Didn't try it with the chipotle app.
Next project!
Here's the data in a spreadsheet
I do think this violates their ToS anyways though.
If it was Unofficial-API-As-A-Service, I'm pretty sure both would be in violation for most services. The user at least for sharing their account credentials, the UAAAS provider likely for some thing in the fine print about only being allowed to use the website for the intended purposes. I doubt either will get sued, the user will get their account cancelled and the provider will get their servers blocked and an angry letter from the lawyers telling them to stop.
The one from this post are self-hosted scrapper-wrapper library API.
The API itself isn't the reason people use the product.
The trading API is very much so official, and dates back to the GDAX days.
The Coinbase "API" in this repo isn't the protocol (eg an HTTP REST API implementation), but the 3rd party Python library which speaks the protocol[1].
The python code is an implementation of a program that uses the Coinbase API to make trades, fetch market data, etc.
In my day, we'd call that a Program, Library or an SDK. Definitely wouldn't call that an "Unofficial API".
When I think of "Unofficial API", I think of an API that wasn't intended for public use and is undocumented and supported by the company. Like the Pandora API some music players have reversed... or the Pokemon GO API people are talking about in this very thread.
Coinbase released, documented and supports their API. Anything that uses that API to do things is just a program, or library.
These implementations are there for devs to save time and simply import the API implementation as a module and use already made functions to do the API calls
The Coinbase team, to my knowledge, doesn't maintain any implementation... making all implementations "Unofficial" in that sense.
I still fail to see how this python code is considered an "Unofficial API".
I used to use unofficial APIs years ago. There's a reason I don't anymore.
If you're interested, I have a newsletter to update you when new repos are added https://forms.gle/e8nCivpTBNftNtgGA and to feature interesting stories from the community.
I'm going to leave the submission up because it struck a genuine chord with people, but that's a lucky escape. Normally, the likelier outcome is bannage.