Diaspora API Dev Progress Report 4

Being in the early phases of getting the implementation started it was inevitable I would encounter a little extra inertia to overcome.  Part of that is my own doing, but all of it is important to have confidence in what I’m developing.  The easiest part was filling out the API Implementation Stoplight chart so everyone, including me, can track what is going on with the development.  Then it was on to a fork in the road of sorts: do I want to start an external test harness now or wait until more is implemented.  I decided for former. 

Why bring on a new development effort right now?  My reasoning goes back to dog fooding your code.  Yes we have very thorough unit tests in the code base.  Yes those are exercising the endpoints.  But in the end this is going to be interfaced with by someone who is on a remote device over an HTTP(S) connection who has to deal with nuances of the authentication, object serialization/deserialization, et cetera.  There is no time like the present do that.  I decided to go one step further and make this a non-Ruby project in a totally separate repository.  You can see the result

here .  It is a Kotlin project that uses Fuel for the HTTP communications.  It says a “test harness” but I’m actually coding up a Kotlin driver layer around the API using the Fuel Routes system.  That makes it possible for someone in Kotlin, or Java, to do something like:

Fuel.request(LikesApi.addLike(postGuid, id_token))

I’m pretty stoked because it’s simultaneously helping me smoke out implementation issues, potential design issues with the API, and (last but not least) lets me finally work on a Kotlin project.

What the testing this way did show was that while the routes were setup correctly there was a configuration issue with the CSRF stuff that I had to address with a configuration parameter.  More importantly it showed that while the returns were correct error modes were not.  This led to me doing an overhaul of the Likes Endpoint’s tests to properly test all error conditions, which then lead to discovering of an inconsistency in the API design with how the underlying Likes service works when trying to remove a like for a user that hasn’t like d the post in the mean time. It’s all down in the details but something to iron out.

Lastly I have done some PRs on some tweaks to the documentation for the API to make it so that the Photos end point documentation points over to the User’s Photos endpoint.  As I was perusing the documentation for a while I thought there was no way to do that, which didn’t make sense of course, and to tweak the posts advanced post contents section from showing up in the list of methods as an artifact to howe Jekyll/Liquid/Kramdown build table of contents.

All around very productive, with the Likes service pretty much done with even more robust tests, and an external test harness to confirm usability and correctness of implementation.   These are very positive developments, but now it’s on to deep diving on another endpoint.