It gets a little fuzzy here since I'm still experimenting, but a POST to the Actor's url will cast a message to the Actor. These verbs are restricted to those that have the ability to perform these actions. Basically, PUT/DELETE/GET on a url will create, kill, or get the current state of an Actor. I've been experimenting with the idea of mixing Actors with REST. I'd like to thank Warren DeLano for giving me an opportunity to blog about our conversations.
You could probably even stream JSON objects, one per line. Perhaps the protocol is used to do all the setup, and then it gives you a URL where you can stream stuff in any format. There might be another server that can output stuff to the screen within an OpenGL context. There might be a server written in C that can use SIMD or the GPU. This platform would allow you to make use of the strengths and weaknesses of any platform such as C, Python, IronPython, MPI in C, etc. For instance, if an app is started in a pipeline, it can output URLs to STDOUT so that the two processes connected via a UNIX pipe can connect using the protocol. It makes sense to do something useful for actual UNIX pipes. If a server returns an error status code, a traceback object in JSON makes sense. Internally, bindings for languages like Python should translate HTTP error status codes to exceptions. Various HTTP status codes should be used in ways that make sense. Various things like HTTP auth may be used. You might even use a list of callbacks in order to create a pipeline. There must be a way of registering a temporary callback URL in order to support asynchronous operation. To support asynchronous operation, you can make an RPC and then pass it a callback URL which the remote server can call later via RPC. GET requests should not have side effects. The method may choose to support GET or POST in the usual RESTful way. There could be alternate syntax for the arguments, such as ?_argument_=some_encoded_json if the JSON structure is deep. Here's what I think URLs should look like: This would convert to a JSON list of args. However, instead of using XML, they use JSON. I'm thinking of a P2P system with many servers who talk to each using RESTful Web APIs, but do so in an XML-RPC sort of way. Such a system could be used with relative easy in a wide range of programming languages, even C. Imagine every RPC function takes one JSON value as input and provides one JSON value as output. That means you should use URLs, proxies, links, the various HTTP verbs, etc. It means you're calling remote functions, but it also means you should take advantage of HTTP as much as possible.
(I know that REST enthusiasts tend to really dislike the RPC style, but bear with me.) That means two things. Imagine an RPC system built on top of REST. While I was doing some consulting with Warren DeLano of PyMOL, we envisioned a REST-RPC hybrid for use in distributed computing. It's everything the Web was never meant to do.and so much more!
0 kommentar(er)
