While I made progress with a few hours of Diaspora API Dev yesterday it wasn’t until today that I finished my first code change towards the API: completing the Likes Endpoint.
I decided to do a relatively fleshed out controller and make a tweak. The Likes Endpoint has three methods: get the likes for a post, like a post, unlike a post. The like/unlike behavior had already been coded but the actual process of getting the likes did not. The underlying LikesService which is what facilitates that behavior in the existing site already supported that so I figured it’d be relatively straight forward to just build on top of that. After sussing out the routes to make sure they were correct to that controller I updated the API LikesController to add a show method. While that did wire things together there was a problem: there was a format discrepancy between the internal structure and the external endpoint. This gave me the opportunity to write my first Presenter. There are some good examples to go through in the code base so that was pretty straight forward. I spent more time trying to make sure the unit tests around the Presenter and the new Controller endpoint worked well. With that change the Likes Endpoint is now feature complete.
The keeping track of where we are and where we need to go is something that I think is important. To get that started I decided to create a Google Sheet that anyone can view in order for them to determine what has been done with the API development. I now need to fill that in for the interim development that has already been done before I got there. As of the writing of this I have columns to capture whether work has not been started, is started but not completed, or completed for each of the method endpoints. The “work” is broken up into discrete elements of: code has been written, tests have been written, merged into the longer-lived API feature branch, merged into the mainline development branch, and if it has been used externally. This last element is probably more ambitious right now than required. I think that ideally I’d like to have a test harness which connects to a server and exercises all of the end points, not just the standard unit testing within the test suite. What I’d write it in and when I do not know.
The immediate next step is to fill in this stoplight chart for the existing code base and then decide on next pieces to develop, which may or may not include building that test harness.