Developer Wishlish for new JSON API

[Slugger]

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.

[rkulagow]

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]

OK, should be synced now.

[rkulagow]

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";)

[cwchapma]

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

(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

[rkulagow]

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.

[cwchapma]

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

[rkulagow]

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?

[cwchapma]

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

[Slugger]

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.