Re: Re: the meaning of stateless

"scott vernon" wrote:
> 
> The function that we are exposing is a reimbursement calculation that
> has many different fields (> 200) 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.  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 make the
> system not "stateless".
> 

This question convinces me that the real "framework" for REST is Xforms.
The plethora of REST frameworks out there ease server configuration, so
I'm not dissing them; just saying that the MVC architecture Xforms
enforces on the client eases application development within the
hypertext paradigm.  Xforms may be deployed to the Web via myriad tools,
which is IMHO easier than coding javascript natively to implement MVC.

Here, unless the function/formula is proprietary and must remain on the
server, I'd put it entirely on the client as the "View" with the tabular
data in its own document, "Modeled" as HTML lists embedded in tables.
The "Controller" can GET/PUT/POST/DELETE this HTML model of the data,
or save it to disk, or whatever.

I'm not saying MVC on the client is REST, or that REST is limited to
MVC.  What I am saying, is where the problem space maps naturally to the
MVC pattern on the client, using Xforms at least to prototype is a no-
brainer as, used properly, it will constrain the developer to REST's
uniform interface.

-Eric