The only reason for trying out sockjs is because of problems with websocket (firewalls etc) and then it seems like a good option to have fallback to http streaming. Do you mean to have a seperate websocket API and a seperate http stream api? Wouldnt it be better if the consumers dont have to choose but that the streaming technology is hidden for them by using a fallback solution?
most API contracts are based on simple network interactions. sockjs is somewhat complex and you'd probably have trouble documenting it as a network interaction, and instead you'd probably end up having to tell your user to use a sockjs client library
if you offer a client sdk of your own, what you could do is have that thing use sockjs to connect. this way users of your sdk don't have to think about protocol