Re: An HTTP EXE Method

> On Apr 4, 2022, at 4:41 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> My understanding of HTTP Methods is that they are designed with the idea of separation of concerns in mind
> 
> Question for the TAG is whether an HTTP EXE method would align with web architecture?
> 
> The method would be similar to POST, in that it has side effects, but it performs just one task, and that is to execute a file
> 
> Example use cases, would be to clean up some logs, to turn on a right, or to play a song.  I'm sure there are many more, as most coders at some time of other have had to called an EXE from an HTTP request, via an API or cgi-bin
> 
> Why not just use POST?  Well, yes you could, I like POST quite a lot.  But EXE commands could be highlighted and sand boxed for extra security, could have their own work flow
> 
> When we created Solid, we had ACLs modeled on the UNIX file system.  RWX, but for the web we had read/write/control.  Where control allows you to change the ACL.  There is a slight mismatch there, as the final bit in UNIX is EXE.  So I have found a gap integrating web / file system / OS which drives my personal curiosity around this Method
> 
> Leaving the practicalities aside, is an EXE Method, I was wondering simply whether such an idea would be in the spirit of webarch.  I've asked a couple of people that I respect in the REST community, and they didnt dismiss it.  
> 
> So wanted to see if I could get any views of the TAG, even just to hear why it's a terrible idea :)

That's not how the Web works. Resources have a purpose that is associated with their
name (URI), not with their file type or storage mechanism or method or media type.

A client doesn't tell the server to execute a file because it is deliberately prevented from
knowing that the URI is associated with a file or that the identifier is associated with
execution of its content. Thus, you can have the same file on the server being executed
via GET/POST on one URI, retrieved via GET on some other URI, and edited via GET/PUT
on yet another URI. Each has its own meaning, with the server applying processing
mechanisms to accomplish the meaning that is specific to URI and method.

Most clients don't need to know how the server does that. The server already knows
whether it needs to be highlighted or sandboxed for security.

The Web is not a remote filesystem, where the resources being operated upon have
a very specific definition (sequence of bytes with attributes) that are then operated
upon directly by clients. Remote file systems have a lot of good things going for them
that the Web does not, and vice versa, but they are too low level to support
information hiding over a long term. They encourage tight coupling.

So, from a Web perspective, what you are looking for is an authoring tool that
specializes in the creation of resources that have an implied execution model
on the back-end, just like editing a CGI script within certain directories has
an implied execution model, or editing java servlets has an implied execution
model once wired into the server config. This is a common theme and can be
found within most Web content management systems, but folks usually
standardize just the execution interface (e.g., CGI on www-tallk, Servlets in JCP)
rather than the authoring interface (e.g., Atom).

Likewise, you can define a server config that "executes" URLs that do not
include a filename extension if there is an associated file with an extension
that indicates it can be executed. There is no need for an EXE method.

Cheers,

....Roy

Received on Monday, 4 April 2022 16:16:58 UTC