One pattern I've seen that might work for you is to use a POST to
create a new resource that represents a set of data points. The
response to the POST is a 303 See Other redirect to the new resource
and the client then GETs that URI.
Marc.
On Jun 20, 2008, at 4:36 PM, Grazi, Victor 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
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.