Re: the meaning of stateless

On Fri, May 3, 2013 at 9:06 AM, Eric J. Bowman <[email protected]> wrote:
> Mike Kelly wrote:
>>
>> Here's how to do the above avoiding violation:
>>
>> POST /submit-search-terms
>> 201 Location: /execute-search?id=123
>>
>> # dependence on context of previous interaction visible via URL
>> GET /execute-search?id=123
>>
>
> Here's how to do the above in harmony with the style:
>
> GET /q?x=submit-terms-search
> GET /q?x=search-submit-terms
> GET /q?x=search-terms-submit
> GET /q?x=terms-submit-search
> GET /q?x=terms-search-submit
> 303 Location: /q?x=submit-search-terms
>
> Dereferencing an alternate word-order may in fact create that resource
> as a side-effect; because it's a side-effect the user-agent doesn't
> need to know that 303 representation was just created.  REST certainly
> doesn't require us to respond 404 when an equivalent resource exists.
>
> Which is the same logic, by which we don't need to POST new searches to
> Google or any other search interface, to "create" them as new resources.
>
> If multiple users, or even the same user, can be expected to (re)enter
> the same terms (in any order), then the goals of the REST style are
> certainly better met using GET so we can cache *how* we got the result,
> instead of just caching the result with no entry link (a la POST).

Obviously.

The point of the example was to show the distinction between
interactions that do and don't violate the stateless constraint. It
wasn't meant to show the perfect way to do search.

Cheers,
M