Re: the meaning of stateless

Thank you Jan,  that was very helpful.

--- In [email protected], Jan Algermissen  wrote:
>
> On 22.04.2013, at 22:51, "scott vernon" vern33nova@... 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)
>
>
>  ...
>
>
> 200 Ok
> Content-Type: application/vnd.foo.reimbursement
>
>
>  ...
>
>
> 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
>
>
>  ...
>
>
> 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
> >>
> >
> >
>