public DDR service using JSON

["eberhard speer jr." <se...@ducis.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As announced here last week I have an "OpenDDR json service" up and
running on one of my servers here.

It doesn't do anything particularly spectacular : it responds to, in
this case a DDR : Device Description Request, with a JSON formatted
key - value 'dictionary' of all the properties and their respective
values for the resolved device's UA, using the OpenDDR resources and code.

What I did try to address is the question of how to get the
UA-to-resolve from the requester -- who also has it's own UA -- to the
DDR service.

In a 'regular' RESTful service a 'query parameter' is part of the URL.
However in this case, an UA as a 'query parameter' in an URL raises a
number of issues :

- - it's *ugly*,
- - it makes the 'service' hard to read thru it's URL,
- - the URL's length could become an issue, but most importantly :
- - UAs can include character sequences that can cause errors and
legitimate security concerns with the receiving server

As a result, I proposed an extra HTTP request header field :
Ddr-User-Agent whose value is the UA-to-resolve.
(http://www.ducis.net/Static/rfc_ddr_api.htm)

Since RESTful requests are constructed 'programatically' putting the
UA in an additional header rather then the URL shouldn't prove to be
much of a coding challenge.

The service is described here (including code examples) :
http://www.ducis.net/Miri/Ddr

You can test the service 'code-less' using a Chrome plugin like cRest
as shown in this screen-print.
http://www.ducis.net/Static/ddr_rest.png

If you think this is a useful proposal, I'll gladly contribute the
documentation and code examples such are they are to the DeviceMap
repository.

Regards,

esjr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ1MPPAAoJEOxywXcFLKYcT7QIAMJVHWJFJ4X9DB7fJelgBNW6
fOCcXc9pezJn8RpQ/0Eg5Jfn5luBUgYLohtELyjx9qgSqD8yw+p8oKFtr0oMLx79
UlHdkFDAcz+FJZtULzH4Jh+PeKKdFUJFICIy62m5bz6K5Qz/NI9AQiSlv477aLxu
yZk3F3dHCInSzdpUb5j9uCmTTmZe0YOYxvNa8TdK1YoGTVlrD18pY/Oz4L6ohwPW
8GsHg/6l0IW7HvcO/L4oFVX4YAykwZwwlLuDZztGG5IS39FPcVbcJWewBoABCKju
JjMlRRWwKRdSbDKogNIlzyr1P41ORP7MG/ySkll1YgwNMaLUOIyDagodTRmD9Vw=
=B6rk
-----END PGP SIGNATURE-----

Re: public DDR service using JSON

[Werner Keil <we...@gmail.com>]

Eberhard,

Thanks a lot for the information.
Especially as member also of JSON JSR EG I might play with the RI (check it
out on java.net if you like, at least Open Source projects will NOT have to
pay WURFL equivalent anual licence fees to Oracle for the JSON Spec;-) and
see, what it can do to consume such service.

Agorava Project is already very JSON capable, that's another place where we
hope to look into it. Oh and there's a meeting of Vienna.js, the local
JavaScript User Group next week, I'll sure tell those guys and probably
even propose it on the agenda:-D

Thanks and Happy Holidays,
Werner
Am 21.12.2012 21:17 schrieb "eberhard speer jr." <se...@ducis.net>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> As announced here last week I have an "OpenDDR json service" up and
> running on one of my servers here.
>
> It doesn't do anything particularly spectacular : it responds to, in
> this case a DDR : Device Description Request, with a JSON formatted
> key - value 'dictionary' of all the properties and their respective
> values for the resolved device's UA, using the OpenDDR resources and code.
>
> What I did try to address is the question of how to get the
> UA-to-resolve from the requester -- who also has it's own UA -- to the
> DDR service.
>
> In a 'regular' RESTful service a 'query parameter' is part of the URL.
> However in this case, an UA as a 'query parameter' in an URL raises a
> number of issues :
>
> - - it's *ugly*,
> - - it makes the 'service' hard to read thru it's URL,
> - - the URL's length could become an issue, but most importantly :
> - - UAs can include character sequences that can cause errors and
> legitimate security concerns with the receiving server
>
> As a result, I proposed an extra HTTP request header field :
> Ddr-User-Agent whose value is the UA-to-resolve.
> (http://www.ducis.net/Static/rfc_ddr_api.htm)
>
> Since RESTful requests are constructed 'programatically' putting the
> UA in an additional header rather then the URL shouldn't prove to be
> much of a coding challenge.
>
> The service is described here (including code examples) :
> http://www.ducis.net/Miri/Ddr
>
> You can test the service 'code-less' using a Chrome plugin like cRest
> as shown in this screen-print.
> http://www.ducis.net/Static/ddr_rest.png
>
> If you think this is a useful proposal, I'll gladly contribute the
> documentation and code examples such are they are to the DeviceMap
> repository.
>
> Regards,
>
> esjr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (MingW32)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQ1MPPAAoJEOxywXcFLKYcT7QIAMJVHWJFJ4X9DB7fJelgBNW6
> fOCcXc9pezJn8RpQ/0Eg5Jfn5luBUgYLohtELyjx9qgSqD8yw+p8oKFtr0oMLx79
> UlHdkFDAcz+FJZtULzH4Jh+PeKKdFUJFICIy62m5bz6K5Qz/NI9AQiSlv477aLxu
> yZk3F3dHCInSzdpUb5j9uCmTTmZe0YOYxvNa8TdK1YoGTVlrD18pY/Oz4L6ohwPW
> 8GsHg/6l0IW7HvcO/L4oFVX4YAykwZwwlLuDZztGG5IS39FPcVbcJWewBoABCKju
> JjMlRRWwKRdSbDKogNIlzyr1P41ORP7MG/ySkll1YgwNMaLUOIyDagodTRmD9Vw=
> =B6rk
> -----END PGP SIGNATURE-----
>