I’ve been working on an iOS GNU social client for a while and along the way I’ve had to learn a bit about how GNU social’s HTTP API works. I thought I would write up a few things I wish I knew before.
The first thing to know is that the GS API typically lets you download information in three formats:
- Twitter-compatible JSON (.json)
- StatusNet XML (.xml)
- ActivityStreams XML (.atom)
You specify what kind of data you would like by putting the appropriate suffix on the end. For example these URLs report this status in the different formats:
JSON is pretty easy to use, especially if you’re building a web client. GS has some extra stuff going on but the Twitter API reference is still really helpful here. The metadata is a bit limited and JSON on the whole does not have great information for parsing out things like mentioned tags or groups. Be warned that if you are using a server that has the Qvitter plugin installed (it looks like slightly old-school Twitter), this plugin adds extra data to the JSON format. If you’re relying on a field, make sure it’s present on a server that does not have Qvitter.
As for StatusNet XML, I don’t really understand what niche it fills so I won’t say anything about it. Have a look at it and let me know what it’s for.
Atom ActivityStreams is a defined standard and so far I’ve found it to have pretty good identifiers for linking data and including metadata like tags and attachments. It is missing some basic information like repeat/fave counts, which I am going to add to GS when I stop writing blog posts and do more coding. I would like to write up a fuller description of the Atom later but you will probably understand it fine if you take some time to read through it carefully. The biggest problem is that it’s verbose.
Using curl to receive and send sample data
It’s super helpful to just play around with the API. On Mac/Linux you can use curl on the command line:
If you would prefer to save it to a file you can do that:
curl -o my_example.atom https://gs.sdf.org/api/statuses/show/1094190.atom
GS supports HTTP basic auth for the API endpoints that require authentication. You can do that in curl straight on the command line. For example to post a status:
curl --user username:password -d "status=Test Post" https://gs.sdf.org/api/statuses/update.json
Paging and updating timelines
When you’re accessing a list of notices you can use the since_id, max_id, page and count parameters to download notices without redownloading, and without accidentally missing any. This is explained super clearly on Twitter’s developer website and the parameters work in exactly the same way on GS. I highly recommend reading it.
Point of interest in the GNU social code
lib/router.php has lots of sections of code like these:
array('action' => 'ApiGNUsocialConfig',
'format' => '(xml|json)'));
It shows that that URLs of the form api/gnusocial/config.XXX are accepted, where XXX can be either xml or json, and the PHP component that handles it is called ApiGNUsocialConfig. You can search for this on the command line using a command like git grep ApiGNUsocialConfig inside the repository where you checked out GNU social. My recommendation would be open up the whole GNU social source folder in an IDE like Visual Studio Code, which will automatically give you nice syntax highlighting and project-wide search.
Once you find out you’re dealing with an API endpoint “ApiGNUsocialConfig” you will find it in a file named apignusocialconfig.php.
This is the file that’s responsible for building up the result and sending it back to your HTTP client. Often they have very good comments describing the interesting parameters and how it works.
If you look at a timeline endpoint like apitimelinehome.php, there’s not a lot of code in it. The process of querying the database for the relevant notices is handled by a subclass of NoticeStream. In this case: InboxNoticeStream.
It is these in these files that the actual SQL queries are constructed, which will help you to understand which notices appear and why.
URLs of interest
To wrap up, here are some interesting API endpoints.
Home timeline (ApiTimelineHomeAction) (authenticated)
Checking if a username and password are correct (ApiAccountVerifyCredentialsAction) (authenticated using credentials under test)