Developer Wishlish for new JSON API

Re: Developer Wishlish for new JSON API

Postby Slugger » Sun Mar 10, 2013 8:41 am

Yeah, everyone should have gotten the latest pull by now. I've heard no complaints to the contrary. When you sync to api 0224, will that mean daily updates will start again? Either way, I'm ready for api 0224.
Slugger
 
Posts: 77
Joined: Sun Sep 18, 2011 1:22 pm

Re: Developer Wishlish for new JSON API

Postby rkulagow » Mon Mar 11, 2013 10:31 am

Daily updates are still being figured out.

I'm going to go ahead and sync the code now. Effective in a few minutes from now you'll need to use API 20130224 to retrieve data.
rkulagow
SD Staff
 
Posts: 911
Joined: Tue Aug 14, 2007 3:15 pm

Re: Developer Wishlish for new JSON API

Postby rkulagow » Mon Mar 11, 2013 10:57 am

OK, should be synced now.
rkulagow
SD Staff
 
Posts: 911
Joined: Tue Aug 14, 2007 3:15 pm

Re: Developer Wishlish for new JSON API

Postby rkulagow » Mon Mar 11, 2013 11:15 am

hall5714 wrote:Posted this on the other thread, so I'll summarize here:
(3) Remove the "submit=submit" requirement from the post object.
If our POST line doesn't have "submit=submit" it just brings up the page form. It shouldn't be expecting a form submission, a simple request=POST_DATA should be enough.


I think I've taken care of this in API 20130311, which is now live on the beta server. ($baseurl = "http://23.21.174.111";)
rkulagow
SD Staff
 
Posts: 911
Joined: Tue Aug 14, 2007 3:15 pm

Re: Developer Wishlish for new JSON API

Postby cwchapma » Fri Mar 29, 2013 8:44 am

I am working on a .net library so I can integrate the new api with Mediaportal's schedules direct plugin and with respect to:

hall5714 wrote:(3) Remove the "submit=submit" requirement from the post object.
If our POST line doesn't have "submit=submit" it just brings up the page form. It shouldn't be expecting a form submission, a simple request=POST_DATA should be enough.


It would be really nice if the post content was just JSON, no "request=post-data", no "submit=submit" and not html encoding of the JSON. I understand why it started out that way but I think most JSON services expect to POST plain JSON and receive plain JSON. JSON is is supposed to remove the fluff and be simple - this complicates the interface slightly.

It seems this could easily be implemented as a separate page, say requestjson.php so that the existing interface isn't broken.

Just my thoughts. Btw, this new api is a great idea. There is a lot of complicated code in our existing plugin that tries to sync up the guide data with thetvdb.com and having it all implemented on the server seems like a far better implementation. Certainly simplifies what I want to do.

Thanks,
Clint
cwchapma
 
Posts: 42
Joined: Fri Mar 29, 2013 8:32 am

Re: Developer Wishlish for new JSON API

Postby rkulagow » Fri Mar 29, 2013 5:15 pm

Well, it's a work-in-progress. Other developer requests have been programmed on an as-time-permits basis.

Send me some links / provide examples of what it might look like and I will take a look.

There is beta code that I've written that already takes data from epguide / tvrage and thetvdb and provides both sources for metadata in case one service or the other is down.

Development will restart once I'm back from vacation and have reliable internet access in a few days.
rkulagow
SD Staff
 
Posts: 911
Joined: Tue Aug 14, 2007 3:15 pm

Re: Developer Wishlish for new JSON API

Postby cwchapma » Fri Mar 29, 2013 6:03 pm

The metadata fetching from thetvdb, tvrage, and epguide is what's got me excited making my project worthwhile.

As far as a simplified interface, instead of the http request looking like this (captured from fiddler):

request=%7B%22randhash%22%3A%2263a423a43e4dec0e0a9fc56dd4f71b2b%22%2C%22object%22%3A%22headends%22%2C%22action%22%3A%22get%22%2C%22api%22%3A20130224%7D&submit=submit

it would look like this:

{"randhash":"63a423a43e4dec0e0a9fc56dd4f71b2b","object":"headends","action":"get","api":20130224}

Hope that's clear.

Thanks for your effort on this,
Clint
cwchapma
 
Posts: 42
Joined: Fri Mar 29, 2013 8:32 am

Re: Developer Wishlish for new JSON API

Postby rkulagow » Fri Mar 29, 2013 6:35 pm

Well, I don't know what fiddler is, but the interface is plain text I think; if you look at the perl script demo stuff you'll see that it's just json-encoding arrays and sending them to the request page.

Is fiddler something like wireshark?
rkulagow
SD Staff
 
Posts: 911
Joined: Tue Aug 14, 2007 3:15 pm

Re: Developer Wishlish for new JSON API

Postby cwchapma » Fri Mar 29, 2013 6:57 pm

The way it's setup now, it still needs to be encoded like it's being submitted from a form and special characters need to be escaped. Ideally, I'd like the content of the http request to just be the json, no "request=" or "submit=" and no escaping special characters.

Fiddler is kind of like wireshark but at the http level instead of tcp/ip. It's a PC program (are you on linux?) that intercepts http requests and shows you what is actually going back and forth.

If it's still not making sense, I could probably set up a webpage that you could go to to trigger the type of request I want to make so you could see what it looks like on the server. If you have a PC, I could show you how to compose a request in Fiddler. Let me know if that would help.

Clint
cwchapma
 
Posts: 42
Joined: Fri Mar 29, 2013 8:32 am

Re: Developer Wishlish for new JSON API

Postby Slugger » Sat Mar 30, 2013 9:17 am

So what's being discussed here is basically reading/writing raw data directly to the in/out streams of the HTTP request. My PHP is rusty, at best, these days, but this would involve processing a request by directly reading the input using something like this instead of accessing things via the POST or GET hashes. And clients would be expected to just dump the raw JSON encoding to the input stream instead of a url encoded html form of the json encoding.

I agree it'd be easier for the client authors if this were done, but not so much easier, imho, that it's worth deprecating any test drivers that may be written using HTML forms, etc. I only say that because, especially for a language like C#, I assume you're using some kind of library to construct the HTTP requests? Encoding the data before sending it along the wire can't be more than a simple method call (and that's only if it's not done "automagically" by the lib you're using). For me, in Java, I'm using the Apache HttpClient lib for all HTTP traffic and the encoding/decoding is done for me without any thought on my end.

All of my FVT tests for the Java client are written in pure Java and don't use any HTML forms, etc. so I'm not worried too much either way. If the switch were made it'd break all the Java client code and so I'd have to fix it so I'd just fix my test cases as the same time. But if someone has web pages for manually testing the service, they may need some serious rework, depending on how they were currently implemented.
Slugger
 
Posts: 77
Joined: Sun Sep 18, 2011 1:22 pm

PreviousNext

Return to Developer

Who is online

Users browsing this forum: No registered users and 4 guests