WebQuery discussion/help (3.12.0 onwards)

TeamSpeak Server
24

Thanks for the explanation. I will check the docs. :slight_smile:

25

I ran into a strange issue with the WebQuery. After 1-2 days it stops responding to my calls. After that I only get a empty response from the server.

My setup is the following:
TS < docker > VM < internal network > pfSense <=> Internet (1:1 NAT (everything except the required ts ports a blocked), Port Forwarding to another IP for WebQuery)
In run in the same internal network another VM with the web application which accesses the WebQuery API. The first configuration I had that it uses the external ip for (the port forwarding i setup in pfsense) to access the API. After about 20 hours it stopped working an responded with empty responses. Then I changed it to use the internal IP of the server and it worked again for about 24 hours and stopped then too.

My only guess now is that there is some sort of rate limit which blocked the ip? I can’t imagine that something is wrong with the HTTP server because then it should stopped working for both external ip and internal IP at the same time. But this wasn’t the case.

Currently if it happens I just restart the teamspeak server and it works again.

PS The web application which accesses the teamspeak does this atleast every 2 minutes (to check the user names) and checks every 5 minutes the groups the users have (<- this code isn’t yet really optimized as it sends more requests as it needs to).

1 Like
26

Would be great! Feel free to send me a repo link if you open sourced it!

28

Whats about the events for the http query? Will we get those?

Another thing… I am writing an API for the http query and things like whoami and version come in arrays even though there will be only one object. Will this be fixed?

29

Under discussion and would like to provide some solution, but don’t have an ETA for you. How would you like to use this?

I do see your point for these two in particular, but in general I don’t love the idea of collapsing single element lists to items (we should be consistent on type), and I also don’t want to special case things like version.

1 Like
30

An endpoint that is streaming events would be great.

So you want to leave the single elements in arrays? It´s ugly in parsing.

1 Like
31

That’d be the plan, but there’s a few different ways we could do that, so curious to hear whether people have preferences for websockets/sse/etc/etc.

I don’t know ; let’s say you had a general command that returned a list like [{‘blah’:1}] - collapsing that list to a single element `{‘blah:1}’ is bad IMO, because now the caller doesn’t know if we return a list or an element. That’s especially annoying for less dynamic languages.

We could instead special-case the ones that only return one (whoami, version, probably a few more), but that’s also quite ugly in my opinion. Returning a list in all cases makes sense to me, but I do understand where you’re coming from.

1 Like
32

Yes, it is in general. But for items that are ALWAYS one I think the special cases are ok… I don´t know how many are there, but I think they are more than whoami and version.

I think sse would be great. It works in most environments and langs.

–

Also… Can you provide a better API-Documentatation than the one coming with the server itself, that also describes ALL parameters and also the return values? Would be really helpful.
Would suggest a website, maybe based on swagger?

1 Like
34

But why should the version command return a list? Are there multiple versions at one time?

collapsing single element lists to items isnt good, i know, but I do not get the point why these are lists at all.

35

@davinciTS i have another suggestion. Could you provide a grpc interface? Would be super cool to have the api spec directly delivered. The api would be written using a grpc compiler for your chosen language.
Event system would be easy via grpc-streams.

36

The problem is there’s no real ‘type’ from the old raw protocol, and the HTTP query isn’t totally separate. If you do, say, a clientlist under raw query, it’ll return either a single item clid=1 cldbid=1... or multiple items clid=1 cldbid=1|clid=2 cldbid=2..., and the client parser is just expected to deal with that.

That doesn’t mean it can’t change in the future, so always happy to read feedback - but it’s designed to be compatible with the original query which wasn’t built with ‘type hints’ in mind.

We definitely hear you! What type of thing would you like to see?

1 Like
37

swagger would be a possibility! Or a simple website.

ok, I see that point and will be quiet about that! It’s great that my feedback is heared!

1 Like
38

@davinciTS if you plan to give out some beta versions for the server feel free to consider me (e.g. for the event system).

39

Then please do it :slight_smile: I mean, there is really no point of returning a version in an array.

I would definitely prefer websockets.

Ps. We should get definitely get a way to interact with the filesystem and icons etc. The old “raw” api was pain in the ■■■ to work with.

40

Websockets are also fine, thats true! But I still hope for a gRPC Interface - that would be gamechanging.

41

How does the help endpoint work?

I tried

  • http://host:10080/help/channellist -> causes 1538: invalid parameter
  • http://host:10080/help?channellist -> causes 5120: out of scope
  • http://host:10080/help?command=channellist -> causes 5120: out of scope

What am i doing wrong? And is the out of scope error correct on that place?

42

help isn’t supported (and probably wouldn’t help, since it would just do what the raw query does - probably not what you were hoping it would do). The ft* commands and use also aren’t supported.

It thinks you’re using the virtual server id ‘help’ → invalid parameter

1 Like
43

Ok, you shoud change the documentation up there. Help is written as available.
{ "help", { manage_scope, write_scope, read_scope, } },

2 Likes
44

I expected the output (body) to be the string that would be in the raw output, after i read the scopes up there…

1 Like
46

Well, everytyhing I really want is a way to disconnect a “client” from the TeamSpeak that is connected by the new WebQuery, since the “quit” and the “logout” is not supported.

I dont like at all the idea of reduce the Query timeout. Is not a solution.

Do you think we will have something soon, @davinciTS? :slight_smile:

Cheers

1 Like