Thanks Paul!
Regards,
Markus
On Fri, Aug 29, 2008 at 3:38 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>
> Markus Kohler wrote:
>
>> Hi Paul,
>> Thanks for you answer!
>> Yes, I agree that that such long URL's are suspicious. But how can I know
>> in advance?
>> I can understand that for the simple identification of objects the URL
>> lenght limit is probably not a problem.
>> But what about queries, where I don't really know how many parameters will
>> be used ?
>>
>> If the query gets too long, do I have to break it up and do more than one
>> request to get to my data?
>>
>>
> That would be up to the service to define. If the service mandates long
> URLs there is no much a client can do about it really.
>
> If a service expects that there could be much state with a query then it
> can mandate that the client POST the query information as form data to a
> general query resource, which creates a new resource and the client can do a
> GET on that created resource to get the results of the query.
>
> Paul.
>
> Regards,
>> Markus
>>
>>
>> On Fri, Aug 29, 2008 at 1:40 PM, Paul Sandoz <Paul.Sandoz_at_sun.com<mailto:
>> Paul.Sandoz_at_sun.com>> wrote:
>>
>> Markus Kohler wrote:
>>
>> Hi,
>> Also in theory there's no limit for the URL length in GET
>> requests, in practice there are limits at least for browsers and
>> maybe also for servers.
>>
>> Is there anything special support in jersey that would help to
>> go around such a limitation?
>>
>> Or is the best practice to just allow all GET's also to be done
>> over a POST (what URL would that have?) and then the client
>> would have to choose POST if the URL is too long?
>>
>>
>> There is nothing specific to Jersey in this respect.
>>
>> Very long URLs make me suspicious of the service design. There is
>> perhaps too much state in the URI that may be better suited as
>> resource state and relationships in hypermedia.
>>
>> Using POST does not really solve the problem because as you point
>> out what should the the URLs of the POST request. An automatic
>> conversion from longer to shorter using a proxy could be very
>> difficult to implement when URLs in representations also need to be
>> converted and the hypermedia might describe how to construct one URL
>> from another (e.g. HTML forms).
>>
>> Services like Tiny URL [1] act as a proxy but i don't think they do
>> URL rewriting. And the intent of Tiny URL is different:
>>
>> "Tiny URL is easier to post on blogs or forums. Email it without
>> wrapping or breaking. Simplify links to your website. Hide an
>> affiliate link. Create personal or unique addresses using a keyword.
>> Tiny.cc turns a ridiculously long URL into a tiny URL... short,
>> meaningful and permanent."
>>
>> Paul.
>>
>> [1] http://www.tiny.cc/
>>
>> -- | ? + ? = To question
>> ----------------\
>> Paul Sandoz
>> x38109
>> +33-4-76188109
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> <mailto:users-unsubscribe_at_jersey.dev.java.net>
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>> <mailto:users-help_at_jersey.dev.java.net>
>>
>>
>>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>