Media Browser Integration

[UncleJohnsBand]

It's not arbitrary data, the MD5 hash makes it url safe it's been working fine for sub an I can't imagine sub accepting a suggestion to change it to a POST. In fact earlier in this thread lukemb3 wanted you to change all your POSTs to GETs Its' not a big deal, I will just got back to using sub's call to login the sid is interchangeable.

Martin

Indeed the sid's between the two should be interchangeable since they are managed by NPVR....they should be one in the same.

Changing from a post to a get from the client should be very simple.... you aren't passing in any objects with the post and the API call format stays the same....all on the url.

As for Instantiate..... could go either way.... I look at it as you are getting the system keys to use the API externally.... therefore it would stay a get.

[UncleJohnsBand]

I wouldn't need to change anything. UJB is providing his own json interface to these, and calling my API classes directly. It doesn't change anything for me if his interface accetps GET or POST or accepts either.

Sub my point was your &md5= on the GET is not bad form just because someone thinks of it is data and you'd have need a better argument then was given to UJB before changing it.

Martin

You are absolutely correct. for sub's xml call which is a proprietary API a Get is just fine.

Since NEWA is using a standard RESTful API implementation using JSON objects the recognized standard would be to use Post when pushing data into the API.

I will admit.... I am not an expert on the standards.....thus I have to be open to tweaks that come across as not aligning to the standard.

And I think I did change some Post's to Gets per request....

Ideally... I would like the NEWA RESTful API to align to REST standards so that using it isn't confusing to those developers who have been living in this space longer than I have.... It's all learning for me.

[mvallevand]

The change is simple, confirming the sid works and that were no security leaks in my 30+ calls over the Internet took me several evenings.


Martin

[UncleJohnsBand]

The change is simple, confirming the sid works and that were no security leaks in my 30+ calls over the Internet took me several evenings.


Martin

Ohhhh....You don't have to retest those 30+ calls do you? This is just a change to one API call that you only need to call once before you make those other calls.....right?

[mvallevand]

Yes, because it is internet I want to be thorough. When you guy iron out what you want I'll rethink using the changes to JSON

The really odd thing here is MB3 doesn't even need the sid, it will be backend to backend on the local LAN.

Martin

[Svekke]

You can implement it as a POST or a GET. It's al up to you.
I asked Luke his opion. And we just implement it as you provide it to us. So you can do what you went.

For MB3 it's indeed the backend on the local LAN. Normally it doesn't run on the WAN...
You can connect with many clients to the MB3 server. The clients could be on the WAN ....

[mvallevand]

If the clients are on the WAN, I'd expect they still connect to MB3 instead of just proxying to NEWA right? To me the big values to NextPVR users for MB3 will be the MP4 transcoded streaming that will be available from your client.

Martin

[Svekke]

Indeed, the clients always connect to our MB3 Server...
NextPvr communicate with the MB3 server only .

[UncleJohnsBand]

You can implement it as a POST or a GET. It's al up to you.
I asked Luke his opion. And we just implement it as you provide it to us. So you can do what you went.

For MB3 it's indeed the backend on the local LAN. Normally it doesn't run on the WAN...
You can connect with many clients to the MB3 server. The clients could be on the WAN ....

I will leave as a Get then.... that way no one needs to do anything.

[Svekke]

Is it true when i say that i don't need the sid value? Or am i wrong?
Or is it better to add to every method?