#1

According to the documentation (and validated by the OpenAPI spec), the GET /2/tweets/search/stream/rules endpoint returns “either a single rule, or a list of rules that have been added to the stream”.

This is problematic for programming languages that have strict type conformance, such as Swift, since there’s no way to represent a union type of either T | Array<T>.

It would be preferable to always return an array, even if that array contains only one element.

2 Likes
#2

Thanks for pointing this out. I can see how this could be a better way to handle the same results for some typed languages and parsers, but I’m not in a position to comment on when / whether that change might be made right now.

I’m going to be passing this along to the engineering team directly. I’ll also point out that we do have a process (Open Evolution) where you can make technical recommendations via GitHub. I’m in two minds whether to firmly recommend using that process for this particular call-out vs the other issue you raised which is more of a bug, but, I wanted to mention Open Evolution here more for your awareness.

Thanks again for thinking about this, and sharing your thoughts!

2 Likes
#3

Thanks for the tip, Andy! I’ll start opening issues there if appropriate from now on. This suggestion does feel like it would be appropriate for that channel!

#4

This is embarrassing; I was working on writing the proposal for open evolution and in so doing discovered an error in my code: I was hitting the stream endpoint rather than stream rules endpoint. Still! I will look forward to opening future proposals :sweat_smile:

2 Likes
#5

Well, thank you for this - that makes me happy, and it means the process seems to have helped, as well! Feedback continues to be welcome via the most useful channels to you, but I’m glad we seem to be all set on this one.

#6