I have noticed unexpected behavior when trying to reply to a Tweet using the REST API.
Whenever I use the POST statuses/update call containing an invalid in_reply_to_status_id value, this property seems to be treated as null. As a result, the reply is treated as a “regular” @mention message. I would expect some sort of error.
The same applies to whenever an inaccessible/restricted in_reply_to_status_id value is used, such as the id_str property of a deleted or protected Tweet which a user does not has access to. In this case, I would expect an error, such as the 179 error:
“Sorry, you are not authorized to see this status”
"Corresponds with HTTP 403 — thrown when a Tweet cannot be viewed by the authenticating user, usually due to the tweet’s author having protected their tweets."
Instead, this reply is treated as a “regular” @mention message as well.
I would like to know if this designed behavior and how to validate the in_reply_status_id property? The validation of the in_reply_to_status_id property does not seem to be automatically done with the POST statuses/update call, is that correct?
How would you advise to validate this value based on validity and accessibility?
By using an additional API call such as the GET statuses/show/:id? I personally would find an additional call a waste, among others considering the API rate limit.
Would love to hear some feedback as I consider the validation of the “in_reply_to_status_id” property a must in order to prevent unexpected, functional behavior.
Obviously the value of this property, based on the original id_str property should never be corrupted, but a use case could be whenever a user A attempts to reply to a public Tweet of user B, while around that same time, that same Tweet is made protected. The reply of user A then makes no sense as a regular message to user B.