New web service clarification needed

[bgowland]

A few questions...

Do all of the new web api calls work as follows...

Code:

http://<server>:<port>/services?<whatever>

What is the difference between client= and sid=? I'm guessing client is a device type and sid is session id. Correct? If so does client have to be a device type with a unique identifier in order to distinguish it from other devices of the same type or is that handled by the sid to make sure the session is unique.

Is it possible to transfer a clone (or impersonate) a web api call? For example, if I build Google Cast ability into nDroid and make a web service request from my tablet, could I then pass it on to my Chromecast with the same session id which then makes a repeat request and gets the same response?

On a lesser note - the future of using JSON? Parsing large amounts of XML with Android devices (mostly older ones) is a PITA due to memory available - JSON is generally more efficient.

Cheers,
Brian

[sub]

The web api I developed have the format http://<server>:<port>/service?method=......

It does require calls to be authenticated. This is done using the method=session.initiate and method=session.login calls, which result in a "sid" that can be then passed to all subsequent calls.

The method=session.initiate call does take a device parameter, and stores it, but doesn't yet do anything different based on device. It may do in future.

This api uses XML. It wasn't really targeting java/javascript, so JSON wasn't really a consideration in it's design. It was really for some earlier PC->PC stuff I was doing. Later I reused it for the XBMC addon. That said, I have added started add JSON support for the calls that return large data sets. ie, calls like /service?method=recording.list&filter=ready&format=json.

This api does not use a "client" parameter. The "client" parameter originally came about to help people that were using VLC etc to watch stream like the /live?channel=x, to help the server know which requests were coming the same client session (so it would know what previous sessions to freeup etc when changing channels). This "client" has also extended a bit further into the touch stuff as well, which is unrelated to the web API above. "client" was just some client side identifier. It could be any unique string.

[bgowland]

It does require calls to be authenticated. This is done using the method=session.initiate and method=session.login calls, which result in a "sid" that can be then passed to all subsequent calls.

The method=session.initiate call does take a device parameter, and stores it, but doesn't yet do anything different based on device. It may do in future.

OK, I hadn't picked up on session.initiate and session.login but related to that side of things, I don't have to do that. Simply using...

Code:

http://192.168.0.5:8866/service?sid=12345&method=setting.list

...for example, actually returns a valid response when I enter it in Chrome browser from my other PC. Is it because authentication isn't needed for LAN connections?

This api uses XML. It wasn't really targeting java/javascript, so JSON wasn't really a consideration in it's design. It was really for some earlier PC->PC stuff I was doing. Later I reused it for the XBMC addon. That said, I have added started add JSON support for the calls that return large data sets. ie, calls like /service?method=recording.list&filter=ready&format=json.

Yes, I'd picked up on format=json but wasn't sure how much it was supported. It would be nice (from my point of view at least) if it was valid for all calls - I could ditch a load of my nDroid SAX parsing code and even trim out a load of the nDroid Service code.

This api does not use a "client" parameter. The "client" parameter originally came about to help people that were using VLC etc to watch stream like the /live?channel=x, to help the server know which requests were coming the same client session (so it would know what previous sessions to freeup etc when changing channels). This "client" has also extended a bit further into the touch stuff as well, which is unrelated to the web API above. "client" was just some client side identifier. It could be any unique string.

OK, thanks.

Cheers,
Brian

[sub]

Yes, I'd picked up on format=json but wasn't sure how much it was supported. It would be nice (from my point of view at least) if it was valid for all calls - I could ditch a load of my nDroid SAX parsing code and even trim out a load of the nDroid Service code.

I hear you, but there is pretty much no chance I'm going to go back and redo it all, so unfortunately you'll just have to live with the xml. Sorry.

[sub]

OK, I hadn't picked up on session.initiate and session.login but related to that side of things, I don't have to do that. Simply using...

Code:

http://192.168.0.5:8866/service?sid=12345&method=setting.list

...for example, actually returns a valid response when I enter it in Chrome browser from my other PC. Is it because authentication isn't needed for LAN connections?

Yes, there is some auto-login stuff that happens for local connections.

[bgowland]

I hear you, but there is pretty much no chance I'm going to go back and redo it all, so unfortunately you'll just have to live with the xml. Sorry.

OK it's your call and I respect that. It's mostly older devices (more specifically older Android versions) which have limited working memory for the VM. I'll just need to take note of what format=json can or cannot be used for.

What about my comment about

Code:

http://192.168.0.5:8866/service?sid=12345&method=setting.list

I obviously just made that sid up - without it I get an "invalid session" response but I can put anything in there and I get a valid response.

Cheers,
Brian

[bgowland]

Yes, there is some auto-login stuff that happens for local connections.

Sorry - overlapped posting. I vaguely remembered the web service allowed security bypass for local networks which is why I wasn't sure.

Cheers,
Brian