RE: [xdi] Agenda: XDI TC Telecon Thursday 1-2PM PT 2008-12-04

Title: [xdi] Agenda: XDI TC Telecon Thursday 1-2PM PT 2008-12-04

Bill, these are all great points and I agree
we need to look at our REST architecture closely. (We might even do something
as radical as consult with Roy directly about it!)

 

One thing RE the schedule today – it
turns out Cordance scheduled their annual shareholder meeting for this
afternoon and I have to do one key presentation at 1:30PM. So I may only be
able to make the first half of the call.

 

Talk to you at 1PM PT.

 

=Drummond 

 

From: Barnhill,
William [USA] [mailto:] 

Sent: Thursday, December 04, 2008
4:46 AM

To: Drummond Reed; OASIS - XDI TC

Subject: RE: [xdi] Agenda: XDI TC
Telecon Thursday 1-2PM PT 2008-12-04

 

 

All,

 

Will do my best to dial in but will be in a car (not
driving) coming back from Virginia at the time.

 

On the Logical vs Physical REST bindings, instead of having
logical HTTP bindings and physical bindings why not have an abstract, protocol
independent, RESTful API based on the std REST operations on a resource of get
current state, transfer state, modify intended state, remove state? One
concrete realization of these bindings would be a mapping to HTTP GET, PUT,
POST, DELETE respectively.

 

Some food for thought from Roy Fielding's blog 'Untangled':

"API
designers, please note the following rules before calling your creation a REST
API:

 
A REST API should not be dependent on any single
     communication protocol, though its successful mapping to a given protocol
     may be dependent on the availability of metadata, choice of methods, etc.
     In general, any protocol element that uses a URI for identification must
     allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not
     separated from interaction.] 

 
A REST API should not contain any changes to the
     communication protocols aside from filling-out or fixing the details of
     underspecified bits of standard protocols, such as HTTP’s PATCH
     method or Link header field. Workarounds for broken implementations (such
     as those browsers stupid enough to believe that HTML defines HTTP’s
     method set) should be defined separately, or at least in appendices, with
     an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces
     are object-specific, not generic.] 

 
A REST API should spend almost all of its
     descriptive effort in defining the media type(s) used for representing
     resources and driving application state, or in defining extended relation
     names and/or hypertext-enabled mark-up for existing standard media types.
     Any effort spent describing what methods to use on what URIs of interest
     should be entirely defined within the scope of the processing rules for a
     media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information
     is driving interaction instead of hypertext.] 

 
A REST API must not define fixed resource names
     or hierarchies (an obvious coupling of client and server). Servers must
     have the freedom to control their own namespace. Instead, allow servers to
     instruct clients on how to construct appropriate URIs, such as is done in
     HTML forms and URI templates, by defining those instructions within media
     types and link relations. [Failure
     here implies that clients are assuming a resource structure due to out-of
     band information, such as a domain-specific standard, which is the
     data-oriented equivalent to RPC's functional coupling]. 

 
A REST API should never have “typed”
     resources that are significant to the client. Specification authors may
     use resource types for describing server implementation behind the interface,
     but those types must be irrelevant and invisible to the client. The only
     types that are significant to a client are the current
     representation’s media type and standardized relation names. [ditto] 

 
A REST API should be entered with no prior knowledge
     beyond the initial URI (bookmark) and set of standardized media types that
     are appropriate for the intended audience (i.e., expected to be understood
     by any client that might use the API). From that point on, all application
     state transitions must be driven by client selection of server-provided
     choices that are present in the received representations or implied by the
     user’s manipulation of those representations. The transitions may be
     determined (or limited by) the client’s knowledge of media types and
     resource communication mechanisms, both of which may be improved
     on-the-fly (e.g., code-on-demand). [Failure
     here implies that out-of-band information is driving interaction instead
     of hypertext.] 

There are
probably other rules that I am forgetting, but the above are the rules related
to the hypertext constraint that are most often violated within so-called REST
APIs. Please try to adhere to them or choose some other buzzword for your
API."

I think
it's important to note that pure REST as Fielding defines it is very tied to
hypertext.  I think he means that it's tied to links and the ability
to traverse them, but what he's said is hypertext.  We probably will not
have a purely REST API, but I think we should aim for as RESTful as possible
given the constraints of the requirements we have already decided on for XRI
and XDI.

=Bill.Barnhill

 

From: Drummond
Reed [mailto:]

Sent: Wed 12/3/2008 8:22 PM

To: 'OASIS - XDI TC'

Subject: [xdi] Agenda: XDI TC
Telecon Thursday 1-2PM PT 2008-12-04

***** NOTE THE NEW NUMBER FOR THIS TELECON ****

***** SAME AS THE NUMBER FOR THE XRI TC TELECON THAT FOLLOWS IT ******

Following is the agenda for the unofficial telecon of the XDI TC at:

Date:  Thursday, 04 December 2008 USA

Time:  1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC)

TO ACCESS THE AUDIO CONFERENCE:

    Dial In Number: 571-434-5750

    Conference ID: 5474

AGENDA

1) PROGRESS OF XRI GCS DELIMITER PROPOSAL

        http://wiki.oasis-open.org/xri/XriThree/GcsDelimiter

2) NEW XRI XREF DELIMITER PROPOSAL

        http://wiki.oasis-open.org/xri/XriThree/XrefDelimiter

3) LOGICAL VS. PHYSICAL REST BINDINGS

As awareness of XDI grows at the Higgins Project, there has been discussion

that the "logical REST binding" of XDI to HTTP(S) in which all
messages are

POSTs does not take advantage of some of the caching and other scalability

features of "physical" REST, where GETs, PUTs, and DELETEs are used.

        http://en.wikipedia.org/wiki/REST

We'll discuss whether we should define both "physical" and
"logical" HTTP(S)

bindings.

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php