Response/Error codes


#1

Your documentation page http://dev.datasift.com/docs/streaming-api/reconnecting has the following to say about response codes:

  1. Non HTTP-200 codes should cause a client to back off exponentially
  2. For more resources on connecting to HTTP streams, it is recommended you consult
    the Twitter documentation on connecting to streams as ours works in a very similar way.

Twitter has a page about the response code that they return:

https://dev.twitter.com/docs/streaming-api/response-codes

Are all the response codes listed there appropriate for datasift as well? Or are there twitter response codes that are not relevant for datasift and/or datasift response codes that are not listed in the twitter documentation? If the latter is true, where can I find information about these codes?

You also have a page:

http://dev.datasift.com/docs/resources/errors

that lists a number of text messages that are returned. How are they returned? Are they returned as payload (HttpEntity) to the http response or in another way? For which http response codes are these messages returned? All the non-200 ones?


#2

All the response codes listed on Twitter's Response Codes page are also appropriate for DataSift - they are all standard HTTP responses.

We have updated our Error Messages page to give some examples of how the error messages are returned (as JSON via your HTTP / WebSocket connection). Many of these errors are custom error messages for our streaming API. 


#3

Thanks for the clarification. Given your response about the twitter response codes being appropriate for datasift as well, I have some questions about your java client. It checks for response codes 200 and 404. If the code is 200 it proceeds with normal processing. If the response code is 404 it gives up. For all other cases it tries to reconnect. But is reconnection really the correct option for response codes such as 401, 403, 406, 413, 416? I can understand that reconnection might be a good option for response codes 420, 500, and 503.


#4

Very good question - thank you for raising this. Requests used to be initially passed through the REST API before starting streaming, which does handle these response codes correctly. I have raised an issue against our GitHub repository for the Java client, so this should be corrected soon.

If you find issues like this in the future, please feel free to raise an issue against the repository, or make a pull request - both are always appreciated!