Subject: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02)

From: Wil Tan <[email-masked]>
Date: Wed, 19 Dec 2012 10:55:03 +1100

I'd like to propose that we use URI query instead of path segments in this
specification.

So, instead of:

  /ip/192.0.2.0/24

Use:

  /?type=ip&q=192.0.2.0/24

or

  /ip/?q=192.0.2.0/24

The main advantage to this approach is that there is a distinction between
a query vs. a known resource. IMO, the distinction is important. The latter
is returned as a full URL in the response body so there's no need to
standardize its representation, but the former is what this draft is about.

When a client is making a query, it may not know a whole lot about the
subject it is querying about. For example, it may not know the CIDR block
prefix and bitmask length.

So, sending a query of "/?type=ip&q=192.0.2.13" may lead me to a stable
resource URL of "/ip/192.0.2.0/24".

A positive side effect is that html forms automatically work without
client-side javascript.

.wil

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 19 Dec 2012 10:16:51 +0800

I think these 3 URIs are equivalent from the perspective of a client. Query string like /?type=ip&q=192.0.2.0/24 usually represents the search result, but URI such as /ip/192.0.2.0/24 is supposed to return an IP representation. For RDAP queries, I think this kind of URI /ip/192.0.2.0/24 is more appropriate, especially in typical REST design.

Regards,

Linlin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wil Tan
Sent: Wednesday, December 19, 2012 7:55 AM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: [weirds] Query vs. Path (comment on draft-ietf-weirds-rdap-query-02)

I'd like to propose that we use URI query instead of path segments in this specification.

So, instead of:

  /ip/192.0.2.0/24

Use:

  /?type=ip&q=192.0.2.0/24

or

  /ip/?q=192.0.2.0/24

The main advantage to this approach is that there is a distinction between a query vs. a known resource. IMO, the distinction is important. The latter is returned as a full URL in the response body so there's no need to standardize its representation, but the former is what this draft is about.

When a client is making a query, it may not know a whole lot about the subject it is querying about. For example, it may not know the CIDR block prefix and bitmask length.

So, sending a query of "/?type=ip&q=192.0.2.13" may lead me to a stable resource URL of "/ip/192.0.2.0/24".

A positive side effect is that html forms automatically work without client-side javascript.

.wil

---

From: Arturo Servin <[email-masked]>
Date: Wed, 19 Dec 2012 10:22:44 -0200

Agreed with Linlin. /ip/192.0.2.0/24 is more appropriate in a REST type
model.

/as

On 19/12/2012 00:16, Linlin Zhou wrote:
> I think these 3 URIs are equivalent from the perspective of a client.
> Query string like /?type=ip&q=192.0.2.0/24 usually represents the search
> result, but URI such as /ip/192.0.2.0/24 is supposed to return an IP
> representation. For RDAP queries, I think this kind of URI
> /ip/192.0.2.0/24 is more appropriate, especially in typical REST design.
> 
>  
> 
> Regards,
> 
> Linlin
> 
>  
> 
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Wil Tan
> *Sent:* Wednesday, December 19, 2012 7:55 AM
> *To:* Hollenbeck, Scott
> *Cc:* [email-masked]
> *Subject:* [weirds] Query vs. Path (comment on
> draft-ietf-weirds-rdap-query-02)
> 
>  
> 
>   /ip/192.0.2.0/24 <http://192.0.2.0/24>
> 
>  
> 
> Use:
> 
>  
> 
>   /?type=ip&q=192.0.2.0/24 <http://192.0.2.0/24>
> 
>  
> 
> or
> 
>  
> 
>   /ip/?q=192.0.2.0/24 <http://192.0.2.0/24>
> 
>  
> 
>  
> 
> The main advantage to this approach is that there is a distinction
> between a query vs. a known resource. IMO, the distinction is important.
> The latter is returned as a full URL in the response body so there's no
> need to standardize its representation, but the former is what this
> draft is about.
> 
>  
> 
> subject it is querying about. For example, it may not know the CIDR
> block prefix and bitmask length.
> 
>  
> 
> resource URL of "/ip/192.0.2.0/24 <http://192.0.2.0/24>".
> 
>  
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: Andy Newton <[email-masked]>
Date: Wed, 19 Dec 2012 14:44:04 +0000

>	Agreed with Linlin. /ip/192.0.2.0/24 is more appropriate in a REST type

I agree with Linlin and Arturo.

-andy

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 19 Dec 2012 12:48:37 -0200

I agree. But, if I read it correctly, the original post aimed to
differentiate between lookups and searches.

I read the original post as:

/ip/10.1.1.0/24 would mean 'i want a lookup for this entry'
/ip?q=10.1.1.0/24 would mean 'search for something that covers this entry'

But I perhaps misread it.

regards,

~Carlos

---

From: Wil Tan <[email-masked]>
Date: Thu, 20 Dec 2012 02:23:42 +1100

> differentiate between lookups and searches.
Thanks Carlos, indeed that's what I meant.

> /ip/10.1.1.0/24 would mean 'i want a lookup for this entry'

Right, and I agree that this is in line with REST style.

Right, it is a "search query", and would probably be most common in the
case of address assignments, because clients are likely to just pass in an
IP, since it wouldn't know the block length.

So for search queries, should we use something like the following?

/ip?q=10.1.1.5 which would return a response or redirect to /ip/10.1.1.0/24

.wil

---

From: Arturo Servin <[email-masked]>
Date: Wed, 19 Dec 2012 15:21:59 -0200

I though searches was out of scope for now.

	Anyhow, it adds some complexity and I do not see the benefit.

/as

On 19/12/2012 13:23, Wil Tan wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     /ip/10.1.1.0/24 <http://10.1.1.0/24> would mean 'i want a lookup for
>     this entry'
> 
> 
>     /ip?q=10.1.1.0/24 <http://10.1.1.0/24> would mean 'search for
>     something that covers this entry'
> 
> 
> case of address assignments, because clients are likely to just pass in
> an IP, since it wouldn't know the block length.
> 
> /ip?q=10.1.1.5 which would return a response or redirect to
> /ip/10.1.1.0/24 <http://10.1.1.0/24>
> 
> 
> .wil
> 
>  
> 
>     >       Agreed with Linlin. /ip/192.0.2.0/24 <http://192.0.2.0/24>
>     is more appropriate in a REST type
>     > model.
>     >
>     > /as
>     >
>     >> Query string like /?type=ip&q=192.0.2.0/24 <http://192.0.2.0/24>
>     usually represents the search
>     >> result, but URI such as /ip/192.0.2.0/24 <http://192.0.2.0/24> is
>     supposed to return an IP
>     >> /ip/192.0.2.0/24 <http://192.0.2.0/24> is more appropriate,
>     especially in typical REST design.
>     >>
>     >>
>     >>
>     >> Regards,
>     >>
>     >> Linlin
>     >>
>     >>
>     >>
>     >> *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     >> Behalf Of *Wil Tan
>     >> *Cc:* [email-masked] <mailto:[email-masked]>
>     >>   /ip/192.0.2.0/24 <http://192.0.2.0/24> <http://192.0.2.0/24>
>     >>
>     >>
>     >>
>     >> Use:
>     >>
>     >>
>     >>
>     <http://192.0.2.0/24>
>     >>   /ip/?q=192.0.2.0/24 <http://192.0.2.0/24> <http://192.0.2.0/24>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> resource URL of "/ip/192.0.2.0/24 <http://192.0.2.0/24>
>     <http://192.0.2.0/24>".
>     >>
>     >>
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>