Markus Kohler wrote:
> Thanks Paul!
No problem. I should also point out that the response to the POST
request can also contain the result contents in the body, and it is not
necessary to create a new resource, which, corresponds to the state of
the query information, if you do not require it.
Paul.
> Regards,
> Markus
>
> On Fri, Aug 29, 2008 at 3:38 PM, Paul Sandoz <Paul.Sandoz_at_sun.com
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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
> <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