Hi Ken,
For a RESTful system the client should not be constructing URIs unless
informed how to do so by representations from the server (e.g. HTML
forms) otherwise it unduly couples the client and service. So the
construction of such URIs, and the placement in representations, is a
server-side issue not a client-side issue.
IIRC i think the RESTful admin service is in accordance with that.
Paul.
On Jun 2, 2010, at 12:03 AM, Ken Paulsen wrote:
>
> In an attempt to summarize our options and the requirements (as I
> understand them):
>
> Requirements:
>
> Path element must be URL safe
> Path element must not be ambiguous
> Path element must not restrict the URL namespace further
> Solution must be generic so it may be applied to any other use-case
> with invalid URL characters
> Solution should be as natural & simple as possible to REST developers.
> Options for '/' within REST path element:
>
> .../management/domain/resource/admin-object-resource/jndi/foo/property
> Security Concerns: ??
> Client Coding issues: None.
> Readability: OK (JNDI name may be confused for part of the path)
> Ambiguous: Yes (JNDI slashes are not distinguishable from the path
> elements)
> Other Issues: Just the ambiguity.
> .../management/domain/resource/admin-object-resource/jndi%2Ffoo/
> property
> Security Concerns: ??
> Client Coding issues: Must call urlencode on JNDI name (simple &
> expected)
> Readability: Good
> Ambiguous: No
> Other Issues: Grizzly may not allow %2F???
> .../management/domain/resource/admin-object-resource/(jndi/foo)/
> property
> Security Concerns: ??
> Client Coding issues: Must know to put parenthesis "()" around JNDI
> name and to NOT urlencode it.
> Readability:
> OK. This is not a typical solution so it looks funny. '/' inside ()'s
> may be confusing (looks like 2 tokens: "(jndi" and "foo)".
> Ambiguous:
> No. However, you need to know the special rules to read it correctly
> (i.e. ()'s have higher precendence than '/'). This is not a standard
> and will be confusing.
> Other Issues: None.
> .../management/domain/resource/admin-object-resource/jndi%252Ffoo/
> property
> Security Concerns: Nothing known.
> Client Coding issues:
> Must call urlencode on JNDI name 2x. This may be confusing as to
> why it
> must be called 2x. However, it is simple to implement since it uses a
> standard encoding.
> Readability: OK. Will be confusing that it is encoded 2x instead of
> the standard of 1x.
> Ambiguous: No
> Other Issues: None.
> .../management/domain/resource/admin-object-resource/property?
> jndiName=jndi_at_2Ffoo
> Security Concerns: Nothing known.
> Client Coding issues: Must call urlencode on JNDI name (simple &
> expected); must add a Query String parameter.
> Readability: OK (see other issues)
> Ambiguous: Yes (see other issues)
> Other Issues:
> Query String parameters are not ordered in Java and cannot be related
> to a particular path element easily. This does not provide good a
> general solution to allowing '/' characters in path elements. It
> makes
> it difficult to read the path as a relative path identifying a single
> object. It also may be ambiguous if more than 1 path element needs to
> allow '/' in its name.
>
> I look forward to discussing this at the admin iteam...
>
> Ken
>
>
> On 06/01/2010 12:00 PM, Bruno Harbulot wrote:
>>
>>
>> On 01/06/10 17:23, Paul Sandoz wrote:
>>
>>>> On 01/06/10 11:47, Andreas Loew wrote:
>>>>> Hi Paul,
>>>>>
>>>>> Paul Sandoz schrieb:
>>>>>
>>>>>>> Not quite: '{' and '}' are just "unsafe" characters,
>>>>>>
>>>>>> They are disallowed in the URI syntax:
>>>>>>
>>>>>> http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.2.4.3
>>>>>
>>>>> while I don't want to argue with you about the subtleties of the
>>>>> fact
>>>>> that curly brackets are *not* part of *neither* "reserved" *nor*
>>>>> "unreserved" characters, it seems to me that the following would
>>>>> be
>>>>> fully sanctioned by the spec:
>>>>>
>>>>> .../management/domain/resources/admin-object-resource/(jndi/foo)
>>>>>
>>>>> because "normal" brackets are "unreserved" characters: "Data
>>>>> characters
>>>>> that are allowed in a URI but do not have a reserved purpose are
>>>>> called
>>>>> unreserved."
>>>>>
>>>>> So how about wrapping resource values that contain "reserved"
>>>>> characters
>>>>> by a pair of (unreserved) "normal" brackets '(' and ')'?
>>>>
>>>> I'm not sure whether you want to take more recent RFCs into
>>>> consideration, but in RFC 3986, which obsoletes RFC 2389,
>>>
>>> Good point. I was using the URI spec that is referenced by HTTP 1.1
>>> (maybe the work on tidying up the HTTP spec will update the
>>> reference?)
>>>
>>>
>>>> parentheses are reserved characters:
>>>>
>>>> http://tools.ietf.org/html/rfc3986#section-2.2
>>>>
>>>> Section 2.4 is probably relevant to this discussion too (especially
>>>> its last sentence).
>>>>
>>>
>>> I am not sure what the last sentence actually means in terms of
>>> parsing
>>> a URI :-) but i strongly suspect for HTTP schemes and the path
>>> component
>>> that '(' and ')' are OK. Jersey does not encode such characters
>>> when URI
>>> building path components e.g.:
>>>
>>> URI u = UriBuilder.fromPath("/(xxx/yyy)/zzz").build();
>>>
>>> BTW IIRC Microsoft's Astoria uses '[' and ']' for delimitation and
>>> those
>>> are percent encoded.
>>>
>>> It would be so much easier if we could use %2F !
>>
>> I guess Jersey might not follow the newer RFC.
>> What I meant with the relevance of the last sentence of section
>> 2.4, is that it more or less implies that, once the path components
>> (separated with '/' have been split) and %2F decoded, further tools
>> in the dispatch chain shouldn't split them further.
>>
>> I wasn't aware of the security issue with %2F and proxy servers,
>> but it sounds more like a case of fixing the way the server behind
>> the proxy interprets them when it shouldn't.
>>
>>
>> Coming back to the original problem... To be honest, I don't use
>> Glassfish every day so I'm not sure whether I'm going to go off
>> topic here, but from a REST point of view, there's no such thing as
>> a RESTful URI (and I think no one had used that expression in the
>> thread so far, so no problem here ;-) ).
>>
>> This is a question that often comes back on the rest-discuss list,
>> but the important point in REST is how you can link and get the
>> resources.
>> Considering that the query part is an integral part of the URI
>> (although some implementations don't necessarily view it this way),
>> these two elements are more or less equivalent in terms of "URI
>> RESTfulness":
>> <a href="http://myblog.example/pages/1">First page</a>
>> <a href="http://myblog.example/?page=1">First page</a>
>>
>> People often think that RESTful systems must have "RESTful URIs"
>> that are query-free. That's not strictly true as far as the REST
>> constraint are concerned from a theoretical point of view.
>> It's mostly an aesthetic matter, which is frankly barely relevant
>> if you follow the hypermedia constraints of REST. Having a query in
>> the URI is often a bad sign when the parameters symbolise actions
>> (e.g. "?action=delete"), so that's probably why they're often
>> discouraged.
>>
>> Whilst <http://localhost:4848/management/domain/resources/admin-object-resource/jndi-foo?convertDash=true
>> > could be considered as symbolising an action (arguable, since it
>> clearly wasn't the intent),
>> it sounds like <http://localhost:4848/management/domain/resources/admin-object-resource/?resource=jndi%2Ffoo
>> > would be just fine.
>>
>> Where having a query part or not matters is in terms of
>> implementation, regarding how the query is dispatched to whatever
>> needs to process that query. That's of course where the problem is
>> here. I think the two main downsides of using a query are that not
>> all proxy cache the requests with queries and that it also makes it
>> harder to use another query on that resource or to build a sub-
>> hierarchy (I'm not sure if it would be the case here).
>>
>>
>> Best wishes,
>>
>> Bruno.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>