Diaspora API Dev Progress Report 16

Brief update from today on the Diaspora API development progress:

• On the Users API turns out we probably still want to have the contacts endpoint if only for the primary user since the Contacts API works on a per-aspect level the way it is mapped.  Whether that method shows up in Contacts API at a different mapping or on the User itself is still TBD but it will be a change to the spec.
• The Post Interactions API is feature complete with full tests and the completed test harness.
• Work has begun on the Notifications API.  This is the first change I’ve done that will require a DB migration, adding a new GUID column to notifications, so this is going to take a bit longer for me to complete as I do background research on that.

At this point it’s actually easier to look at what is left to do versus what we have done (which is a huge plus sign):

• The only two endpoints that haven’t been touched are Photos and Search. Once these are done (along with work on Notifications) the entire API spec will have been implemented.
• Implement a new poll interaction method for answering a poll through the API
• We need to implement paging on several of the endpoints.  This technique will be similar to how it’s done in the core controllers but it has to be different because the return type needs to have the next/previous pages and the corresponding format needs to honor that.  The actual mechanics of the queries are pretty much the same though so grafting them into the existing feature complete controllers should be relatively easy.
• Right now the OpenID integration works well enough for testing but it currently requires revalidating the app every 24 hours.  This has to be tweaked to be more reasonable.  There may be some refactoring in there as well.
• The Posts API Endpoint accepts any photos currently, including those that are already attached to another post.  This is not consistent behavior and has to be corrected to only allow a “pending” photo to be added.
• Sweep of all of the APIs for consistency on security, service initialization (where appropriate), params parsing idioms, etc.
• Sweep through the unit tests to make sure that edge cases are covered in the same way
• Documentation updates to account for things discovered during the development (error codes added, format tweaks etc.)