OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Honestly... the number of threads going simultaneously is making the convesation mass confusion for me. I guess its a good sign about our progress, but we really need to get all this on the wiki :)

- Mike



On Thu, 24 May 2012, Markus Sabadello wrote:

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<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>
<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>
<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<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<xdi-unsubscribe@lists.oasis-open.org>
For additional commands, e-mail: xdi-help@lists.oasis-open.org









[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]