Re: [xdi] How to send XDI message to server?

[Markus Sabadello <markus.sabadello@xdi.org>]

Hello Yuriy,

Thanks, yes thinking of these two interfaces separately clears up a lot of confusion. :)
I.e. 1. A way to send a complete XDI message, and 2. An HTTP REST interface.
I think we definitely need Interface 1, and I guess Interface 2 could also be useful.



Would the two interfaces have to reside at two different URLs on the server?

Interface 1.:
---------------- 
I think I'd still prefer the message in the HTTP body rather than in a parameter, but your approach with a "message" parameter would work too.
Probably we want to have content negotiation to determine the request and response format.


Interface 2.: 
-----------------
If we pass multiple addresses or statements in an "xri" or "xdi_statement" parameter, then we're working with multiple resources at the same time.
I don't think that can still be considered RESTful.

Also, I agree with Bill's following statement:
> I’d prefer it if we require every address to serve as an endpoint for operations at that address. 

In other words, in REST, the URI identifies the resource you're working on, and in our case the resources are XDI addresses.
Unfortunately, this means that if one of your query parameters changes (e.g. sender or link contract, etc.), the resource also changes, which is not what we want.
So like Bill suggests, it might be better to use HTTP headers instead of query parameters.

BTW what is a Graph ID? And why is the following statement needed at all (question to Drummond)?
@!9999!8888$msg!1234/$()/(=!1111!2222)

Also, I'm not sure if the following syntax in your examples is correct:

@!9999!8888$msg!1234$do/$add/(=!1111!2222!3/()/+tel)

@!9999!8888$msg!1234$do/$add/(=!1111!2222!3/()/+birthdate)

I don't think we've ever talked about cross-references being used for $add operations.


Markus

On Thu, May 24, 2012 at 11:30 AM, Yuriy Zabrovarnyy <yzabrovarniy@gmail.com> wrote:

Hi all,

I'm a little bit lost with this discussion. Are we talking about just transfer XDI Message Request over HTTP or we are talking about standardize REST for XDI Messaging?
I thought the goal is to really provide standard for REST which is based on HTTP. I propose to separate discussion on 2 major topic because it's a little bit messed :).

1. Standardize XDI Message Request tranfer over HTTP (not REST)
As basis OX Server idea can be taken. There all statements of request are encoded into JSON and is passed as parameter "message". In this case both GET and POST http methods handle this parameter. Response is transfered in payload of http response.

2. Standardize XDI Message Request for REST
Here main difference is that goal of REST is to provide convenient interface for developer and REUSE existing HTTP vocabulary.
I still think XDI operations can be perfectly binded with HTTP methods. (see  wiki http://en.wikipedia.org/wiki/Representational_state_transfer). Does anybody see any problems with this approach? If yes, then describe in details what is the exact problem.

GET    - retrieve - $get
PUT    - replace  - $mod
POST   - create   - $add
DELETE - delete   - $del

With REST client that sends XDI Message Request does NOT need to know how exactly xdi statements should look. Client just pass parameters and xdi statements are constructed and handled for him.

a) GET
Consider following request:

@!9999!8888$msg!1234/$()/(=!1111!2222)
@!9999!8888$msg!1234/$d!/(data:,2011-04-10T22:22:22Z)

@!9999!8888$msg!1234/$do/=!1111!2222!3$do
@!9999!8888$msg!1234$do/$get/=!1111!2222!3+tel
@!9999!8888$msg!1234$do/$get/=!1111!2222!3+birthdate

As draft proposal REST GET parameters may look like:
- message_sender - @!9999!8888
- message_num - !1234
- graph_id - =!1111!2222
- date - 2011-04-10T22:22:22Z
- xri - =!1111!2222!3+tel, =!1111!2222!3+birthdate -for target of $get operation
While there is no definitive standard parameter with the same name can be used to pass multiple values (see wiki http://en.wikipedia.org/wiki/Query_string)

b) POST
Consider following request:

@!9999!8888$msg!1234/$()/(=!1111!2222)
@!9999!8888$msg!1234/$d!/(data:,2011-04-10T22:22:22Z)

@!9999!8888$msg!1234/$do/=!1111!2222!3$do
@!9999!8888$msg!1234$do/$add/(=!1111!2222!3/()/+tel)
@!9999!8888$msg!1234$do/$add/(=!1111!2222!3/()/+birthdate)

As draft proposal REST POST parameters may look like:
- message_sender - @!9999!8888
- message_num - !1234
- graph_id - =!1111!2222
- date - 2011-04-10T22:22:22Z
- xdi_statement - =!1111!2222!3/()/+tel, =!1111!2222!3/()/+birthdate -for target of $add operation

c) PUT (similar to GET and POS)
d) DELETE (similar to GET and POS)

Thoughts?

Yuriy Z

On Thu, May 24, 2012 at 11:10 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

If we pass the message in a query parameter, and if either GET or POST can be used, then that's not RESTful.

My proposal of just POSTing the message in the HTTP body isn't RESTful either.

With both proposals, one could still argue that we're RESTful on the XDI layer, albeit not on the HTTP layer.

What other information would you pass as additional query parameters?
Sender, link contract, token, etc?
Wouldn't those things be part of the message itself, rather than outside of it?

Markus

On Thu, May 24, 2012 at 4:58 AM, Michael Schwartz <mike@gluu.org> wrote:

If we use a query parameter, we can support both GET and POST. Plus we will have the option to use other query parameters to pass additional information.

If putting the message in the POST message directly has no advantages, and a big disadvantage (not suppriting GET), and not as much flexibility, I'm having trouble understanding the allure.

Can someone explain to me why we would not want to use query parameters? Or alternately, why just supporting putting the message in POST is advantageous?

- Mike

On Wed, 23 May 2012, Joseph Boyle wrote:

How closely do we want to bind XDI to HTTP? If there is someday a good reason to bind it to another transport, we might not want to be tied to HTTP-specific features.

At most the HTTP verbs are only going to match a little of the semantics of XDI, and it's not clear if they even match that bit well.

I would keep it simple with XDI HTTP servers MUST implement only plain submission of XDI via POST, MAY implement some other shortcuts if called for but those shortcuts may be withdrawn or changed in later versions.

Parameters would be needed if there is request information not expressible in the XDI query syntax itself, otherwise they are an optional shortcut.

GET would make queries bookmarkable but as said that would work only with public resources, and the main use case for XDI is access control.

On May 22, 2012, at 11:27 PM, Markus Sabadello wrote:

Like I said, semantics of POST and PUT don't map directly to semantics of $add and $mod.
Of course we could decide that this doesn't matter and that we just do what works.

What parameters would you propose?

Markus

On Tue, May 22, 2012 at 11:40 PM, Yuriy Zabrovarnyy <yzabrovarniy@gmail.com> wrote:
It's important to keep REST interface obvious for others. Direct request transfer via POST cut down advantage of REST and looks more like direct transfer.

1. It's good approach to reuse existing stuff with REST. Mapping between HTTP methods and XDI operations looks pretty natural. See this link
http://en.wikipedia.org/wiki/Representational_state_transfer#Vocabulary_Re-Use_vs._Its_Arbitrary_Extension:_HTTP_and_SOAP

2. Parameters with REST is widely used, for example see OAuth or OpenID specification. I don't see any reason why do we try to avoid parameters usage.

Regards,
Yuriy Z


On Wed, May 23, 2012 at 12:24 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
The GET shortcut is limited and only for the public part of the graph. It could be nice for some situations, but I agree it's not necessary.

Everything can simply be done with POST. Everything needed to execute the message should be in the message, which goes into the HTTP body. HTTP query and fragment should not be used.

Markus

On Tue, May 22, 2012 at 11:18 PM, Michael Schwartz <mike@gluu.org> wrote:

Markus,

And where would you communicated references to link contracts?

Multiple operations in one message?

Where would the sender be specified ?

Prima facie, it seems like your design would only be useful for requests to the $public part of a graph. Perhaps this should be specified as an additional MAY feature a server may implement. But I'd rather see one initial comprehensive solution before we support a shortcut.


- Mike




On Tue, 22 May 2012, Markus Sabadello wrote:

Okay, here's my proposed design.

* A message is sent via HTTP POST (as the full HTTP body, not
encoded as a parameter)

* As a convenient shortcut, HTTP GET is treated like an XDI $get operation
on a single XDI address passed in the URL, e.g.

GET /=markus+email HTTP 1.1
becomes something like
$$msg!1$do/$get/=markus+email

* HTTP DELETE is not supported

* HTTP PUT is not supported

* No HTTP query string or fragment or form-encoded parameters are used

* An Accept: header can be sent by the client to indicate the desired
response format, e.g. JSON, or list of XDI statements.

* A Content-Type: header is sent by the server to indicate the actual
response format.

Markus

On Tue, May 22, 2012 at 11:03 PM, Michael Schwartz <mike@gluu.org> wrote:


Markus and Joseph,

Propose a design... but obviously, we need to address how all elements of
the XDI message would be communicated, not just the operation.

- Mike





On Tue, 22 May 2012, Markus Sabadello wrote:

 Thanks Joseph for re-sending..

For an XDI Developer list, I think Google Groups would be easiest.

Yes we have talked about an HTTP REST binding in the past..

The semantics of GET and $get, as well as those of DELETE and $del seem to
be the same, but mapping $add and $mod to POST and PUT is difficult. We
can
of course do whatever we want, but REST purists won't like it.

I don't think any HTTP query parameters should be used.

Markus

On Tue, May 22, 2012 at 10:39 PM, Joseph Boyle
<planetwork@josephboyle.net>**wrote:


 Markus, this is Yuriy and Drummond's replies - forwarding to your gmail
since it sounds like your xdi.org mail lost them.

On May 13, 2012, at 9:32 PM, Drummond Reed wrote:

Yuriy,

Thanks for sending this. I really wish you could join the TC directly so
you could be part of these discussions - we have talked quite a bit
about a
pure REST binding for XDI, and I think there is agreement on your mapping
of the verbs.

I think we're going to reinstate either the XDI Google Group or start a
new XDI.org mailing list on XDI so we can have discussions with XDI
developers who are not on the TC.

Mike, Markus: it makes sense to me that XDI.org should host the XDI
Developer mailing list. If we are going to redo the website, what are our
options for a new mailing list? Or should we restart the Google Group?

=Drummond

On Sat, May 12, 2012 at 3:35 AM, Yuriy Zabrovarnyy <
yzabrovarniy@gmail.com

wrote:


 It's very good idea to standardize REST for XDI Messaging. A few points
from my side:

1. HTTP GET

Please consider following example from
http://wiki.oasis-open.org/**xdi/XdiMessagePatterns<http://wiki.oasis-open.org/xdi/XdiMessagePatterns>

@!9999!8888$msg!1234/$()/(=!**1111!2222)
@!9999!8888$msg!1234/$d!/(**data:,2011-04-10T22:22:22Z)
@!9999!8888$msg!1234/$do/=!**1111!2222!3$do
@!9999!8888$msg!1234$do/$get/=**!1111!2222!3+tel
@!9999!8888$msg!1234$do/$get/=**!1111!2222!3+birthdate


Approach with inlined $get operation can NOT be used because here are 2
$get operations.
E.g. GET /=markus+email HTTP 1.1

As solution parameters can be used to pass $get operation nodes.

2. It's important to specify exact names of parameter as it's made for
OAuth and OpenID standards. Except operations message request also
contains
link contract address, graph id, sender and authentication information
(e.g. token).

3. XDI operations as HTTP methods
According to wiki (
http://en.wikipedia.org/wiki/**Representational_state_**transfer<http://en.wikipedia.org/wiki/Representational_state_transfer>)

these
binding between HTTP methods and XDI operations looks logical to me.
GET    - retrieve - $get
PUT    - replace  - $mod
POST   - create   - $add
DELETE - delete   - $del

To summarize it makes sense to provide sample how exactly XDI Message
Request from oasis wiki can be made via REST web service with exact
parameters.

(I can't send email to oasis mail list, therefore mail is sent only to
people who is in my contact list.)

Regards,
Yuriy Z

On Sat, May 12, 2012 at 12:18 AM, Joseph Boyle <
planetwork@josephboyle.net> wrote:

 Yes XDI2's looks like a canonical REST interface. I like it.

Sent from my iPhone

On May 11, 2012, at 1:28 PM, Markus Sabadello <
markus.sabadello@xdi.org>
wrote:

Oops sorry I made one mistake..

* HTTP GET is treated like an XDI $get operation on an XDI address
passed in the URL, e.g.

GET /=markus+email HTTP 1.1
becomes something like
$$msg!1$do/$get/=markus+email


On Fri, May 11, 2012 at 10:26 PM, Markus Sabadello <
markus.sabadello@xdi.org> wrote:

 Hi all,

During today's XDI TC call I mentioned XDI Messaging.

The one concrete issue I'd like to figure out is how exactly a message
is sent from an XDI client to an XDI server.

As far as I know, current implementations work like this:


OpenXDI:
-------------

* A message is passed as a "message" parameter, either via HTTP GET or
POST

* No asynchronous XDI messaging supported


XDI2 / Project Danube:
-------------

* A message can be sent via HTTP POST (as the full HTTP body, not
encoded as a parameter)

* HTTP GET is treated like an XDI $get operation on an XDI address
passed in the URL, e.g.

GET /=markus+email HTTP 1.1
becomes something like
$$msg!1$do/$get/=markus

* HTTP DELETE is treated like XDI $del

* HTTP PUT is treated like XDI $add

* An Accept: header can be sent to indicate the desired response
format, e.g. JSON, or list of XDI statements

* No asynchronous XDI messaging supported


I have heard several people say that XDI needs an interface that is
RESTful on the HTTP level.

Please discuss on this thread, then we can create an page on the TC
wiki.
BTW there are lots of pages on the TC wiki that need updating.

Markus













---------------------------------------------------------------------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xdi-help@lists.oasis-open.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xdi-help@lists.oasis-open.org