twitter-compatible API: POST /statuses/update.json

[carols10cents]

This is a smaller story broken out from #562.

This issue is just to make POST /statuses/update.json work like the twitter API. This route doesn't currently exist at all, but there is a nice update json decorator for you to use.

Ignore the issue of client authentication for the moment; just make this work as a normally authenticated user in the browser for now (see #564 about authentication)

https://dev.twitter.com/docs/api/1/post/statuses/update

Description: Updates the authenticating user's status, also known as tweeting.

Definitely interpret anything in the twitter docs so that it makes sense for rstat.us, and definitely ask if you have any questions!

Leave a comment if you're working on this.

[thomaslee]

Happy to look at this one. What do you mean by a "nice update json decorator", though?

[thomaslee]

Ah, found it -- never mind.

[thomaslee]

Some early work here: https://github.com/thomaslee/rstat.us/commit/3b8c3553026f45dd52349340e068120ce5282c8e

WIP Branch: https://github.com/thomaslee/rstat.us/tree/twitter-api

It's not entirely clear to me if you feel we should be striving to match Twitter's API as closely as we can. I'm assuming so if we want to try & be compatible with existing clients?

Also, how do you feel about moving the API stuff into its own namespace as I've started doing on this branch? We could also try to lay this on top of our existing updates controller, but I think it may actually be cleaner to separate them out if we're going for compatibility with Twitter's API. Otherwise we'll introduce a whole lot of mess in UpdatesController extracting different input parameters depending which output format is selected (e.g. :text => params[:status] if params[:format] == "json", otherwise :text => params[:text] ... ?!).

I think if the shared logic could be crushed down a little further, the benefit of splitting the Twitter/JSON API into a separate (set of) controller(s) should be more readily apparent.

In any case, I think longer term it's going to be worth collaborating a common branch for all of this stuff. None of the twitter-compatible API tickets can really be addressed in a vacuum.

[steveklabnik]

I'm assuming so if we want to try & be compatible with existing clients?

Yes, many Twitter clients let you change the endpoint. See https://github.com/hotsh/rstat.us/issues/562#issuecomment-7818137

[thomaslee]

Yep, saw that. In that case, it's possible to play with the code on that branch with a POST /api/1/statuses/update.json & the obvious inputs per the Twitter spec. Still some cleanup to do, but you get the idea. Will look at that & test failures tomorrow, when it's not 4am. :)

[carols10cents]

Yep, the real test for all of these is if it works with the existing clients.

I'm in favor of namespacing the twitter API routes-- since twitter has '1' in their base URL (blech), we should be able to add a namespace to the base URL.

I'll create a common branch for collaboration on dependent things, and that will probably be very useful for getting started and finishing, but I do think some of the API actions are independent of each other and could be merged to master before all of them are done.

[carols10cents]

Ok I started a branch for combining work on this: https://github.com/hotsh/rstat.us/tree/twitter-api

I've got your commit on there, @thomaslee, and a commit of mine-- I'd like to see if we can avoid having versions in the url ;)

I'm working on some tests but haven't pushed that yet, I'm having trouble getting some old capybara session tricks working to stub out the authentication, so it's looking like I should get moving on that ;)

[thomaslee]

Cheers Carol! Pushed an extra commit before I saw your email. Fixes the tests I broke. Afk for a bit if you'd like to merge it in, or I can do it later. :-)

[thomaslee]

Opened a pull request for the change to address the failing tests in #587.