I love REST! This is perfect, thanks!
On 6/20/08, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
> 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.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>