http://api.hubski.com/publications
http://api.hubski.com/publication/266825
It's REST/JSON. Right now, you can only get a list of all publications, and any specific publication. Publications include both posts and comments. Only public data is available—you can't get mail, deleted, or drafts, even your own. Because there's no login mechanism.
It's also a little rough around the edges. For example, you'll see keys for search_text, search_title, and search_url. Those are used internally. They'll be removed from the external API at some point.
This obviously isn't enough to make anything interesting, like a mobile app. But you can play with it.
For the immediate future, I'll probably be alternating between adding to the API and making the main app more scalable.
No promises, but feel free to make requests.
EDIT: added an endpoint to get all children of a publication recursively in a single request:
http://api.hubski.com/publication/266825/tree
EDIT: changed API from hubski.com/api to api.hubski.com.
vigorously launches Visual Studio Awesome. As a side project, I am currently learning how to parse an XML from Transport for London's API into Python (and put it into GIS). Parsing a JSON shouldn't be much more difficult. mk didn't you have the idea to allow geotagging on posts?
insomniasexx had that idea. We all dig it, but aren't surr how much it would be used.
Yeah, I also like the idea but lack a good use for it. A map of discussions / articles would be cool though. It would add another layer of customization / classification. I'm not sure if the added benefit would outweigh the effort. But if you do, there is a handy API by Google to add a places library.
So this is what I imagined. I always imagined it would be third party and didn't think about how all the tags would be linked up or whatever. It's not logistical at all but whatever. I would love to be able to have posts tagged with a location. For a lot of posts, location won't matter. This one for example, has no location and should not have one. However, posts that are about a particular place could be tagged and added to a map: For example: New York: Death Valley: Appalachian Trail: Area 51: Then I could visit a (third-party site) and a map would appear. I could go into New York and see a bunch of cool posts related to New York. It could be really, really cool.
Yes! But I was also thinking of adding the location to posts as something you can follow, e.g. next to #thehumancondition it could say "Area 51", with a link to all the posts geotagged with that location. I could then subscribe to all Area 51 posts. But that's probably really difficult to do because there can be multiple names for the same thing, because you could also tag that post with "Nevada Desert" or "Nevada". Maaybe it could work if you can only subscribe to administrative areas - countries, states and counties/municipalities. The result could probably feed into a map in some way.
It would probably be necessary to hook into a map API that has full addresses, etc. That way when I enter Death Valley, I don't just see Death Valley posts, it also (automatically) falls under California and United States. This would obviously be way more helpful for smaller countries that don't have as many posts. While some people might be specific and say "Kabul", for most items it would probably be "Afghanistan". We wouldn't want the one post that was specifically tagged "Kabul" to not appear when the other 9 posts were simply tagged Afghanistan. I still envision this as a third party site that hooks into the Hubski publications and links back to Hubski. It doesn't 100% jive with what Hubski does and it adds another layer/layers to the already far-from-perfect tagging system. Plus, integrating a map API(s) into Hubski's current set up could be a bit of a server hit due to our infrastructure. And the reward, on Hubski.com, isn't really worth that. One way to get posts tagged is to show 5 or so random posts and 5 of the newest posts and have people tag them every time they visit the site. Slowly but surely, the map would begin to fill out. I also have a feeling that a lot of posts wouldn't have a location.
Yes, that makes more sense. An implementation with a smaller server footprint would require a prefetched list of places and areas, though. The hierarchy in the list (LA County inside CA inside the US) could still provide something useful. And for the posts that don't have a location, there's always Null Island.
This is glorious! Thank you so much. I've got a script I wrote to screen-scrape comments and embed them on other sites a la "Discussion via Hubski". Having access to a JSON API will make things a million times easier. I'll see if I can convert it over tomorrow (public holiday — yay) and let you know how it goes.
I have some working code and it's waaaaay neater than the screen-scraping I was doing previously, but I don't know if I can use it regularly yet. If I want to get comments for a publication, I have to get that publication and then recursively do additional HTTP requests for each comment, each comment on those comments, etc. If I'm doing this for more than one publication, this adds up quickly to a large number of requests, which takes ages and puts a bigger load on the Hubski server. I know you're busy, but if you get the chance my feature request would be for an end-point that lets you get a publication and all its child publications in one go. Instead of "kids" being an array of publication IDs, it would be an array of publication objects, and those child objects would have their own "kids", etc. That way you can get the whole post and all its comments in one request. This would be in addition to the existing end-point so users can choose which one they want (and not unnecessarily incur huge queries on the Hubski DB). You could call it /publication/{id}/tree or something similar. Thanks again for the great work! I can't tell you how long I've been looking forward to this API. I make these bloody things for a living, so please let me know if I can help out at all.
Ye gods that was quick — thanks so much! I'm now happily using the new end-point and loving it. I made public all the updates to my screen-scraping plugin Static Discussion via Hubski. This plugin is designed to be used with Pelican, a static website generator, but the code is fairly basic Python and could easily be cribbed for other purposes. I also defined all the URLs in a conf file so that the end-points can easily be updated without revving the code. If you decide on a better name than "tree", I can just redefine the end-point in the settings.
I've been ambush-badged! Thank you, insomniasexx — you move in mysterious ways.
It took me embarrassingly long to get the hang of combining Python 3 and the API, but once I understood what I was doing I made this small script. I put it up on Github. Any criticism is welcome, I'm not a Python expert. The script that gives you a sorted list of everyone who voted on a post or comment. For example, for rob's post it returns this in the command line: Title: Hubski prototypical API is here List of votes, sorted from first voter to last: 1: thenewgreen 2: War 3: mk 4: caelum19 5: camarillobrillo 6: forwardslash 7: nowaypablo 8: thundara 9: StJohn 10: OftenBen 11: demure 12: am_Unition 13: ihya1324 14: veen 15: whanhee 16: tauta_krypta 17: NoTroop 18: lelibertaire 19: Cumol 20: querx 21: KittehCult 22: aeromill 23: GodOfAtheism Press Enter to exit... It ain't perfect but I think it's cool that I conjured this up in a few hours. insomniasexx or rob, how can I get a simple .py like this up on the web as something that runs on a server? As in, an online version of the command line that runs my file. I tried some of the services from this free Github student pack but I am such a webdev noob that I don't have a clue what does what. I've heard of Docker, is that what I'm looking for? Pub ID: 266825
Sort of... it's power is as version controlled packaging / deployment. The config files let you say "install all of these dependencies, run services for a reverse proxy / search engine / database, hook them together like so, run X copies across a farm of machines, and expose these ports / directories within their file systems." What sets it apart from other similar programs (Puppet, Chef, Ansible, Vagrant) is that instead of running those programs in virtual machines or the hose machine, they are run within containers. This means less overhead than a VM, but also somewhat different security concerns
That's much more user friendly than what I conjured up. I, too, am a total webdev noob. I'm currently moving my site to a virtual private server, so I can do some webdev on there too. The goal is to build a simple web app, learning Django along the way. I've got a page that displays text, now all I need to do is put all the useful stuff in there...
It's the reason I also list whether it is an upvote or down vote in the newest version of the code. At first I only displayed upvotes, but that meant that a post could display more upvotes than its counter. Instead of adding a check for up-down combinations, I just added '...voted up'.
Here's a non-command line fork of your project; I hope you find it helpful: https://github.com/imbellish/HubskiScript/blob/master/Hubski/Hubski.py
Docker is completely unrelated. You can write a basic Python web server. Example, Docs. Alternatively, if you want a static web page, you can rewrite your script in Javascript. Then, you can serve the html+javascript from any dumb web server, e.g. Github Pages. Tutorial. If you want to go the Javascript route, let me know, and I'll add CORS headers to the API server, which you need to make an XSS request.
When I go to the http://api.hubski.com/ page, I can't access unless I log in again? And it's an unsecured page? No https?
Still getting this : Mixed Content: The page at 'https://hubski.com/pub?id=266825' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://api.hubski.com/publication/266844'. This request has been blocked; the content must be served over HTTPS.
It doesn't sort, the order is arbitrary. Sorting is expensive. Users can sort on their side, if they need to. It's also likely that endpoint will go away. I'm having a hard time thinking of a scenario where it's necessary or useful. Bulk downloading hubski data maybe; but if we want to support that, we can provide a more efficient method.
