DELETE url

[J. Landman Gay]

This has been a fascinating discussion and you guys have been very helpful. 
Gotta thank Charles for the ready-made handler and Stephen for the even 
shorter one.

I read Charles' first and told the Rails programmer that I could indeed 
send DELETE but it would take some scripting I'd never used before so we'd 
need to test. (Later I saw Stephen's.) She said "oh, never mind, it will 
take me 5 minutes to turn it into a POST." So once again I have managed to 
dodge the bullet and Dar should be happy as well.  :-)

Please do carry on, I might even learn something.

--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On July 6, 2019 10:24:32 AM Dar Scott via use-livecode 
<use-livecode at lists.runrev.com> wrote:

> Oh, RFC2616 is so twentieth century.
>
> However, RFC7231 HTTP/1.1 agrees with the responses: 200 (OK), 202 
> (Accepted), or 204 (No Content).
>
> It does have a couple examples that seems to indicate that DELETE might be 
> used for logout, should one have imagination:
>
> 	DELETE might be used to remove a resource previously created with PUT (as 
> I described).
>
> 	DELETE might be used to remove a resource previously created with a POST 
> that returns a 201 (Created) status.
>
> POST is favored for login, or so it seems from a quick search. POST is a 
> command, an action. A wide range of status responses are allowed. So, 
> perhaps the first login returns a 201 (Created) and subsequent logins 
> either create new sessions (201) or return the same session (200). I think 
> I saw a few cases where the responses were 200 and 404. Use of 200 with 
> POST means that a proxy must have POST caching turned off or tweaked.
>
> The 201 might return something like 
> http://www.example.com/api/jj73koaiekdyu33/ 
> <http://www.example.com/api/jj73koaiekdyu33/>. The session key is part of 
> the URL. Subsequent queries would use this as the base URL. DELETE would 
> delete that.
>
> This makes DELETE look more acceptable as logout.
>
> However, this falls apart when we look at authentication. A token is 
> usually not returned in a 201 as part of a session URL, but is more often a 
> value that is returned in the authentication header for subsequent use of 
> the session. It can also be returned as a cookie and subsequent requests 
> use the cookie. In these scenarios, the semantic coherence of DELETE starts 
> to fall apart.
>
> Also, login and logout are verbs. That seems to vote for POST for both.
>
> Yet, give me the protocol and I will work with it. I am not really as 
> cranky as I claim.
>
> Dar Scott
> DarScott at darzLab.com
>
>> On Jul 5, 2019, at 8:07 PM, Mark Wieder via use-livecode 
>> <use-livecode at lists.runrev.com> wrote:
>>
>> On 7/5/19 6:13 PM, Dar Scott Consulting via use-livecode wrote:
>>> And an aside. Off topic.
>>> I guess I am old-school. I know it is the fad, but using DELETE to logout 
>>> seems goofy. Yeah, you can make a URL that looks like a session and you are 
>>> deleting the session. But it seems that is like using HEAD to indicate what 
>>> direction you are going or OPTIONS to set up options.
>>> I know. I'm a cranky curmudgeon. I survive by recognizing that this is no 
>>> longer HTTP, but a wolf in sheep's clothing to get past firewalls, a whole 
>>> new protocol where we make it up as we go.
>>> Now, given that, and I join the 21st century, DELETE returns a status code 
>>> and an optional content. The status code is normally 204 (but maybe 205, 
>>> which might be appropriate for log out) when no content is returned or 200 
>>> if content is returned. If the item is not there, the same applies, but 
>>> perhaps 404 or 410 can also apply. If DELETE is used to mean logout, then 
>>> the session is permanently gone and 410 on a repeat is appropriate. A 303 
>>> is OK (content is URL), but is probably handled by the underlying library.
>>> Now, for proper symmetry, if DELETE is used to log out, then PUT must be 
>>> used to log in. Both are idempotent, so logging in multiple times should be 
>>> OK and logging out multiple times should be OK.  That is, a login returns 
>>> 200 and a logout returns 204.  Every time.
>>> I have not seen it implemented that way. We play the hands we are dealt.
>>
>> RFC 2616 describes only three possible responses to a DELETE verb:
>> 200: the response includes an entity describing the status
>> 202: the action has not yet been enacted
>> 204: the action has been enacted but there is no status entity
>>
>> Idempotence appears to be optional. RFC2616 states that certain verbs "can" 
>> have this property. That said, not all servers or web apps support the 
>> DELETE verb - there's usually an option to enable/disable it.
>>
>> And I'm with you on the weirdness of using DELETE to log out. Bleah.
>>
>> But to Jacque's point, see this:
>> <https://stackoverflow.com/questions/10338615/sending-http-delete-request-in-android>
>>
>> --
>> Mark Wieder
>> ahsoftware at gmail.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode