You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2016/06/16 15:56:26 UTC

Re: Restful Objects - Simple Arguments vs Format Arguments

Hi Kevin,

sorry not to reply sooner on this.

The simple vs formal scheme relates to the representations that are
returned from a resource, not the representations of the arguments sent to
the resource.  So, the format should be the same irrespective of which
scheme type your RO implementation supports.

The relevant sections (of RO v1.0 spec) is 2.9 and 2.10.

HTH
Dan



On 28 May 2016 at 19:15, Kevin Lewandowski <kl...@discogsinc.com>
wrote:

> Hi, all. I'm working on an early python implementation of RO and had a
> question about passing arguments.
>
> In an Action Invoke resource, is there a way to tell if the client is
> sending arguments in the Simple scheme vs Formal Scheme? I can't find this
> anywhere in the spec.
>
> thanks,
>
> Kevin
>

Re: Restful Objects - Simple Arguments vs Format Arguments

Posted by Kevin Lewandowski <kl...@discogsinc.com>.
Thanks Dan! I was referring to the format of the arguments.

I dug into the Isis source code earlier and found that it attempts to
determine the format of the arguments, so it would work either way and the
client was not responsible for specifying what format the arguments were.

thanks,
Kevin

On Thu, Jun 16, 2016 at 8:56 AM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:

> Hi Kevin,
>
> sorry not to reply sooner on this.
>
> The simple vs formal scheme relates to the representations that are
> returned from a resource, not the representations of the arguments sent to
> the resource.  So, the format should be the same irrespective of which
> scheme type your RO implementation supports.
>
> The relevant sections (of RO v1.0 spec) is 2.9 and 2.10.
>
> HTH
> Dan
>
>
>
> On 28 May 2016 at 19:15, Kevin Lewandowski <kl...@discogsinc.com>
> wrote:
>
> > Hi, all. I'm working on an early python implementation of RO and had a
> > question about passing arguments.
> >
> > In an Action Invoke resource, is there a way to tell if the client is
> > sending arguments in the Simple scheme vs Formal Scheme? I can't find
> this
> > anywhere in the spec.
> >
> > thanks,
> >
> > Kevin
> >
>

Re: Restful Objects - Simple Arguments vs Format Arguments

Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Ah, re-reading your question, I think maybe you are talking about the
format of the arguments, not the concept of simple vs formal schemes.
Apologies.

So, in which case, no... there isn't a direct way, but the server can
attempt to unmarshal the query string as if formal argument (ie a URL
encoded json string), otherwise fallback to attempting to treat as a set of
key=value pairs.

The Isis implementation also has (proprietary) support that combines these;
the special query param "x-isis-query-string" can be used whose value is
the URL encoded json string.  I added this mostly for my own testing... my
recollection is that when using the "Postman" extension (in Chrome) for a
post/put, it used to assume foo=bar syntax.  (since been generalized to
accept anything as the post/put body).

HTH
Dan


On 16 June 2016 at 16:56, Dan Haywood <da...@haywood-associates.co.uk> wrote:

> Hi Kevin,
>
> sorry not to reply sooner on this.
>
> The simple vs formal scheme relates to the representations that are
> returned from a resource, not the representations of the arguments sent to
> the resource.  So, the format should be the same irrespective of which
> scheme type your RO implementation supports.
>
> The relevant sections (of RO v1.0 spec) is 2.9 and 2.10.
>
> HTH
> Dan
>
>
>
> On 28 May 2016 at 19:15, Kevin Lewandowski <kl...@discogsinc.com>
> wrote:
>
>> Hi, all. I'm working on an early python implementation of RO and had a
>> question about passing arguments.
>>
>> In an Action Invoke resource, is there a way to tell if the client is
>> sending arguments in the Simple scheme vs Formal Scheme? I can't find this
>> anywhere in the spec.
>>
>> thanks,
>>
>> Kevin
>>
>
>