-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all,
the DDR Query service announced earlier (Proposal for DDR Queries, 08/12) is online. To tie in with Werner's earlier suggestions to get "a more lively discussion" going : REST/JSON services ================== I haven't had, or rather made, the time yet to fully document the service on the site, but it ties in with the REST/JSON services mentioned by Werner. The service doesn't really do anything 'exciting', yet. It responds to a GET request, with the additional *Ddr-User-Agent* header (!), with JSON serialized OpenDdr property-value pairs. (I also have a version that responds using protobuf.) Basically, I want to establish a standard method for such services which can be used irrespective of the underlying DDR, platform or the REST-services built on top of it. My main concern was to get the user-agent string parameter out of the URL because : - - it's ugly - - makes the URL/service hard to 'read' - - and the wild collection of often weird characters that can occur in a user-agent string, even when encoded, can cause problems in the URL query string. A C# implementation would look something like you see below and would presumably best be implemented at the start of a user session so that the response can be stored in a session cache for reference throughout the session. In .Net the global.asax Session_Start event handler would be the place to do this; I'm sure other stacks offer similar opportunities. // service URL string serviceUrl = "http://www.ducis.net/Ddr";; // Response HTTP Status Code int status = 0; // Response JSON string string jsonDictionary = ""; // DDR Request WebRequest request = WebRequest.Create(serviceUrl); // additional request header ! request.Headers.Add("Ddr-User-Agent", request.UserAgent); // DDR Response WebResponse response = request.GetResponse(); status = ((HttpWebResponse)response).StatusCode; switch (status) { case 200: // success using (StreamReader reader = new StreamReader(response.GetResponseStream())) { jsonDictionary = reader.ReadToEnd(); } // do something useful : // 1 - deserialize json string // 2 - store in session cache as dictionary/hashmap // 3 - ... break; case 204: // empty response : Ddr-User-Agent of unknown device // OR not a mobile device (!) break; case 400: // bad request : Ddr-User-Agent Http request header was missing break; default: // oops break; } You can also test the service using a tool like the cRest plugin for Chrome. I have attached a screen-print of such a test fyi. (You can get cRest here : https://chrome.google.com/webstore/detail/crest-client/baedhhmoaooldchehjhlpppaieoglhml) When the documentation is ready I plan to make this service available, as-is, free, without registration etc. to any and all. Flat files ========== As some of you may know my Miri is basically a fork of the OpenDDR project. My main objective there was to make the resolver(s) independent from the underlying data-source. So Miri can load the OpenDDR resources from the original XML, via an RDBMS (MS SQL, MySQL,...),from Redis or any other data-provider that can be tied to the data-interface of Miri. The current online version uses 2 flat files which are little more than the original OpenDDR XML resources but serialized to JSON. (Actually, the XML is loaded in an SQL server, some sanity checks are performed and queries extract data which is 'massaged' in dictionaries/hashmaps which are then serialized to JSON and written to the flat files.) This greatly reduces the size of the resource files and it allows Miri to load all the data in its cache on start-up *much* faster (average load time : 430 ms) leaving the 'competition' far behind. I'm also thinking of giving it a go using protobuf serialized resource files -- yes, I've got this 'thing' with protobuf ;-) To be clear =========== Obviously, I'm not looking to 'sell' Miri here -- although I do hope to get some 'commercial' millage out of its services elsewhere. I just want to contribute ideas, techniques, technologies and lessons learned from a live system and use that live system to implement and test some of the ideas coming out of the, I hope, soon "lively discussion" here. Looking forwards to you comments etc, esjr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQyTOxAAoJEOxywXcFLKYcuSQIALZgGzEJuVhDrvkU4Oj90W49 Nd4InpNc520MOPLO5e2WAPM2EF5RCsOWS3UadBv+fBP+jMH9PHpw7wmDEo59B/ka O+gqq9a4M+42nRiPYmUg+K86EVl/afTjtfZXbbSpmymo71FVspKOgKMBLT7KAo17 KgvCd5uUC9PHrJMLekSCzH9vaq1ACkPAUmArwDQUGHaLgOY86OlXAqFZrGIXMZkZ bZubZZojB/8byhol7KJnNuwq4xazck6t4gGc3OiDf9Z7xiTS9OxOt+mpcsJddx3h Sjlk7F7ImxhSzvLLruoBc/gLv+i6JMBP2KKrgHrjK3KEtzmQX0zexLaD0WhPKDc= =aMyR -----END PGP SIGNATURE-----
