GET =~ _optUncall?

[Dan Connolly]

When uniform messaging protocols are mapped into HTTP (e.g. waterken web_send, q-connection) everything tends to go via POST. The application style where the first fetch gives you a tiny bit of HTML that fetches the rest of the page via javascript never sat well with me, but I can see how object capability security motivates it.

But a while ago when I was porting the safe serialization stuff from E to monte, it occurred to me that _optUncall could / should be mapped to GET.

Does that match anyone else's intuitions?

--

Dan Connolly

http://www.madmode.com/

[Kevin Reid]

On Wed, May 1, 2019 at 2:51 PM Dan Connolly <dc...@madmode.com> wrote:

When uniform messaging protocols are mapped into HTTP (e.g. waterken web_send, q-connection) everything tends to go via POST.

POST is a necessary evil if there is not enough information to know that the operation is relevantly almost-side-effect-free. If there were an object system which had a strong convention for marking some methods as "getters" then it would be reasonable to map those to GETs.

 

… But a while ago when I was porting the safe serialization stuff from E to monte, it occurred to me that _optUncall could / should be mapped to GET.

Does that match anyone else's intuitions?

Do you mean "__optUncall is an example of a method that could be accessed by a GET rather than POST request", or do you mean "a GET operation on a HTTP resource should correspond to an __optUncall message to an underlying object"?

For the former: yes, absolutely. Miranda methods are an example of the sort of strong convention I mentioned above.

For the latter: sort of. The abstract fuzzy conceptual meaning of GET, as I see it, is: "tell me the things I should reasonably know about this thing at this moment". __optUncall is very much like that conceptually, except for two things:

1. Often __optUncall returns something which is not informative about the contents of the object, but rather instructions for where to fetch it (e.g. specifically in E, consider an emaker serializing as its name so that the corresponding emaker is loaded on the receiving side). From the HTTP perspective, this is a non-answer to GET.
   
2. By default, a mutable non-serializable object returns null from __optUncall. Typically, a mutable HTTP resource returns its current state in response to GET.

Therefore, a HTTP layer over E-style objects should make __optUncall or analogues available as a HTTP GET, if that makes sense, but it should not make that the interpretation of all GETs.

[David Nicol]

another practical consideration is that GET requests tend to get cached as immutable, even when they have data, while POST requests are generally passed through. If the system being designed is supposed to work even through caching proxies.

… But a while ago when I was porting the safe serialization stuff from E to monte, it occurred to me that _optUncall could / should be mapped to GET.

--

"Plant yourself like a tree beside the river of truth and tell the whole world: No, you move."