Re: Re: the meaning of stateless

On 22.04.2013, at 22:51, "scott vernon" <[email protected]> wrote:

> Thank you for your response.
> 
> The function that we are exposing is a reimbursement calculation that
> has many different fields (> 50) that could alter the outcome.  Some of
> the fields are basic flags and others are lists of items that could be
> empty or up to as many as 100.  There isn't really any hierarchy to the
> data or any value to expose them as resources individually.  Providing
> the data in a POST would work but then the concern is we need to store
> the output of the formula, which also contains a good amount of fields,
> on the server in order to respond to the future GET.  

Which future GET? Why not just POST the query and consume the result? Yes, you loose visibility and thus cacheability of the result, but given the myriad of parameters reasonable cache hit ratio seems unlikely anyhow.

So, either I am missing the point, or you should just

POST /service/calculator
Content-Type: application/vnd.foo.reimbursement (or whatever)

<calc-params>
 ...
</calc-params>

200 Ok
Content-Type: application/vnd.foo.reimbursement

<calc-result>
 ...
</calc-result>

and be done. Add boxes at will to scale. It's ok, to just use POST.

If you need caching, because the result will be re-used, you could store the result (as a static file, maybe), assign it a URI and tell the client (and caches on the way) about it:


200 Ok
Content-Type: application/vnd.foo.reimbursement
Content-Location: http://static.foo.org/calculation-resuts/7qjy6s
Location: http://static.foo.org/calculation-resuts/7qjy6s

<calc-result>
 ...
</calc-result>

That way, you could share the static resource with other 'users' and use a phalanx of caches (replicated using a standard cache protocol) to serve up the result in the future.  

----

In the end, you are right though. Keeping the result on the server creates server side state - but this is ok, if you assign it a URI. And yes, you essentially need to distribute that across all servers in order to scale. This is a normal situation, such as with accounts of new users or uploaded photos to Flickr.

One way to deal with that is caches that replicate, another is trading the 'C' of the CAP theorem for the 'A', use a NoSQL DB in the backend and deal with the (occasional if at all) lack of consistency.

Hope that helps.

Jan


> We are eventually
> going to feed this service into a larger application and would like to
> be able to scale as we get large amounts of data fed through.  If the
> result data is stored in memory, we would lose the ability to scale out,
> and in essence would make the system not "stateless".
> 
> My developers think that using SOAP so that the result of formula can be
> returned in one transaction is the best way to solve this problem.  I
> believe in REST but I don't' know if adding a database to hold the
> result data outweighs the benefits or if using a overloaded POST is
> better than the SOAP solution.
> 
> 
> --- In [email protected], Jan Algermissen  wrote:
>> 
>> And if you really have to:
>> 
>> On 22.04.2013, at 20:56, "scott vernon" vern33nova@... wrote:
>> 
>>> so where would we store the intermediate data
>> 
>> Build up the state on the client. Why does the intermediate state need
> to be on the server in the first place? Why not just POST the large
> 'query'?
>> 
>> Jan
>> 
> 
>