Re: How to express no matching results in HTTP SEARH method?

> On 4 Nov 2020, at 14:56, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> --------
> Julian Reschke writes:
>> Am 04.11.2020 um 14:24 schrieb Poul-Henning Kamp:
> 
>>> It might be a good idea to hash out a couple of general mechanisms
>>> in the spec, to provide mechanisms for traffic/load-engineering,
>>> at the very least something like "Dont-repeat-this-SEARCH: <seconds>" ?
>> 
>> That's all very interesting, but why is this relevant now, but not for
>> existing uses of POST we want to replace?
> 
> Because this is the century of the fruitbat, and we're trying to do a better
> job than back in the dark ages where things were just slapped together ?
> 
> Because SEARCH has much narrower and therefore more manageable semantics
> than POST, which can literally be and do anything ?

Structurally I think the following is true:

- POST creates a new resource - so it can have consequences like filling 
    a shopping cart or enrolling in the army
- GET fetches a representation without the client being bound by anything more
   than having seen the result. 

SEARCH (when restricted to one resource) is just a more  efficient GET,
just like PATCH is a more efficient PUT.

Henry

> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
>

Received on Thursday, 5 November 2020 03:20:46 UTC