RE: [Policy] identifying APIs

Hi John,

Would it be possible for you to share [API]?

Why would we need APIs to be resources? (I know it is possible, but ...)
APIs are used to retrieve resources / data / information that may have URI representations.
So we would end up in URIs retrieving URIs retrieving URIs and so on.
I believe the level of detail plays the role here.

We had similar discussion in BONDI a few months ago.

I think we could take WebIDL and try to make URIs from the WebIDL structure as an example.

E.g.
module mod1 {
 interface if1 {
  void f1(in DOMString p1, in unsigned long p2);
  void f2();
  attribute unsigned long a1;
  };
};

Then we could have quite simple URIs:

http://www.w3.org/dap/api/mod1/if1/f1
http://www.w3.org/dap/api/mod1/if1/f2
http://www.w3.org/dap/api/mod1/if1/a1

or

http://www.w3.org/dap/api/mod1/if1.f1
etc.
and we could even invoke such api with parameters and their values:

http://www.w3.org/dap/api/mod1/if1/f1?p1=oo&p2=2

The problems could start if we would have module in module structure [1].
Those could be overcome by some syntaxes if we would need.

As in [2] I just wonder about the goal of such a representation, specifically to express security dependencies that should be compact IMHO.

Thanks,
Marcin

[1] http://www.w3.org/TR/WebIDL/#idl-modules
[2] http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0064.html
________________________________________
From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of John Kemp [john@jkemp.net]
Sent: Tuesday, October 06, 2009 7:58 PM
To: Frederick Hirsch
Cc: W3C Device APIs and Policy WG
Subject: Re: [Policy] identifying APIs

Hi Frederick,

Frederick Hirsch wrote:
> Earlier I listed some of the higher level requirements and goals to
> consider for DAP API Policy [1]. One of these was:
> "10. Able to identify an API by URI"
> I should note that URI need not be the only approach, though my
> inclination was to start with URI.
>
> An example of the first approach, using a URI, is BONDI 1.01 which
> defines IRIs for the various APIs (section 4.2 BONDI architecture and
> security [2]).
>
> A second approach is to use class names, as Marcin noted in the Access
> workshop position paper [3]  - APIs could be identified by Javascript
> class name and optional property attribute (see the table in 3.3).
>
> A third approach is to not name APIs at all, but pass material in the
> API invocation to enable use, passing a capability. But for an
> enforcement engine to evaluate declarative policy it  would still need
> to be able to name APIs, I would think.
>
> This raises a couple of questions: is the DAP API work restricted solely
> to Javascript or should the model support other languages (degree of
> language independence needed), and does declarative policy require the
> ability to name an API (regardless of whether feature access control is
> included).
>
> It seems to me we need naming and that URIs offer more flexibility. Is
> this a decision easily made, or is discussion required?

+1 to using URIs to name APIs. As I suggested in an early draft document
I presented to the TAG a couple of weeks ago [API], I think an API can
be thought of as a (set of) resource(s), which have representations.

If you were to expose the same APIs via a device-hosted HTTP server,
what would the URIs look like? Could a URI identify the same resource,
regardless of whether that resource is accessed as a Javascript function
call or via an HTTP access?

Cheers,

- johnk

[API] http://www.w3.org/2001/tag/2009/09/apis-on-the-web.html
(member-restricted, I believe)

>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-device-apis/2009Sep/0126.html
>
> [2]
> http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_v1_01.pdf
>
>
> [3]
> http://www.w3.org/2008/security-ws/papers/ACCESSPositionPaper_W3CSecurityWorkshop.pdf
>
>
>



________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Tuesday, 6 October 2009 21:35:48 UTC