You could post the query criteria to create a new resource and then
retrieve it via GET.
Stefan Tilkov
On Jun 20, 2008, at 22:36, "Grazi, Victor" <victor.grazi_at_credit-suisse.com
> wrote:
> I have a REST methodology question - if not appropriate for this
> forum,
> please forgive and redirect me if you would.
> (But I would love to hear the REST pros weigh-in!)
>
> We are designing a financial forecasting Web Service using Jersey.
>
> Clients would request a "CompanyScenario" resource, essentially a
> container for about 50,000+ data points per company, calculated on the
> server. (Example data points would be ROI at year 2007 and EBITDA at
> year 2010.)
>
> So for example, a client could call for
> "/resources/companies/IBM/scenarios/default" which would return the
> default scenario for IBM.
>
> Most applications would not need all 50,000 data points for a
> scenario,
> and those would take up over 5MB which would be overkill to return on
> each call.
> In fact, most applications would only need about 1000 data points
> from a
> scenario, though we would never know which in advance.
>
> So the problem is how should the client tell the server exactly which
> data points it needs?
> We were thinking of having the client pass in the names of desired
> data
> points as query string parameters, but that URI could easily exceed
> 4KB,
> which would exceed the limits on URI size.
>
> On the other hand, using HTTP POST violates the contract of GET gets
> stuff and POST creates stuff.
>
> The O'Reilly RESTFul Web Services book touches on this briefly, and
> suggests appending .1, .2, .3 to represent specific variations of a
> resource. But this doesn't really work for us, because a client
> needs to
> be able to request ad hoc sets of variables, many at a time.
>
> I am wondering if there is a best practice suggestion for this common
> use-case?
>
> Much thanks, Victor
>
> ===
> ===
> ===
> =====================================================================
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
>
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ===
> ===
> ===
> =====================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>