Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix documentation typo in favorites.rb #619

Merged
merged 1 commit into from Oct 1, 2014
Merged

Conversation

arronmabrey
Copy link
Contributor

I think these should be favorite! not favorite because this is documenting the favorite! method.

-- Arron

I think these should be `favorite!` not `favorite` because this is documenting the `favorite!` method.

-- Arron
@arronmabrey arronmabrey changed the title FIx documentation typo in favorites.rb Fix documentation typo in favorites.rb Oct 1, 2014
@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 46858e5 on arronmabrey:patch-1 into 96c211c on sferik:master.

@sferik
Copy link
Owner

sferik commented Oct 1, 2014

Nice catch.

sferik added a commit that referenced this pull request Oct 1, 2014
Fix documentation typo in favorites.rb
@sferik sferik merged commit e3aa3ac into sferik:master Oct 1, 2014
@arronmabrey arronmabrey deleted the patch-1 branch October 1, 2014 19:37
@arronmabrey
Copy link
Contributor Author

@sferik I found it while a co-worker and I were trying to see if all the api type methods had bang ! counter parts that raise exceptions. We didn't really conclude one way or the other, do you know the answer to this question? What if any list of methods can we rely on to raise exceptions if the thing we are trying to do fails, as opposed to returning some falsely value.

@sferik
Copy link
Owner

sferik commented Oct 1, 2014

@arronmabrey There are only three public methods of a Twitter::REST::Client that offer bang versions:

  1. update!
  2. retweet!
  3. favorite!

According to HTTP POST semantics, these operations should not be idempotent. Specifically, calling any of these methods with the same arguments multiple times will result in an HTTP 403 Forbidden error after the first success. It seemed reasonable to provide safe, idempotent versions of these methods that ignore these errors, to emulate the semantics of an HTTP PUT, which I believe is a better model for retweeting and favoriting.

Any method, including the non-bang versions of the methods above, can raise an exception (e.g. Twitter::Error::Unauthorized) but these methods will never raise the corresponding Twitter::Error::AlreadyPosted, Twitter::Error::AlreadyRetweeted, or Twitter::Error::AlreadyFavorited errors.

@arronmabrey
Copy link
Contributor Author

@sferik wow, thanks! That's great information, thank you for taking the time to write it up for me :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants