m0smithslash's Journal: REST stands for REpresentational State Transfer

REST stands for REpresentational State Transfer

FrontPage - RESTwiki

REST stands for REpresentational State Transfer. The basic idea is to simplify rather than add complexity. The reason for the success of HTTP is its simplicity. There are a few well-understood and simple commands that a web-server supports. Any other program can access the data on the web server. There is nothing tying either the server or the client to a specific platform.

UNIX pipes are similar. A very simply interface that allow for powerful systems to be build without undue complexity. Wouldn't it be great if the GUIs of the world allowed programs to be "piped" like command line programs.

In the shell, you "create" a pipeline by entering the command like:

ls -s | sort -n > /tmp/sortedlist

What this does is to start two programs, sort and ls. The output from the first is read by the second. The output from the second is written to the named filed. The pipes don't need to exist on a single computer but can be run over a network.

So why does this work?

1. The is a shell that allows for the creation of a pipeline of programs
2. There are a set of programs that accept input from STDIN or output to STDOUT or both
3. There is a way to order the execution of the programs such that the output of one program is read by the input of another
4. There is a way to terminate the pipe so that the output of the final program is written either to a terminal or to a file. Actually terminals and files look the same.
5. The programs produce the data in a well understood way. The format of the output of ls -s is always the same.

So what would it take to have "pipelined" GUI elements? First off, just as in the command line version, you wouldn't need to see the data as it flowed through the GUI pipe. So the data would flow in a non-GUI way.

Ok, to create a pipeline. First, the GUI would need a pipeline tool like the shell. It could be a gui based tool or support a command line like bash. With a GUI tool, you could have a pallet of programs that you place on a pipe looking background. At each point in the pipe, a sample output of the program could be shown.

Next, we need a set of pipeline-able gui tools. The source tools already exist: ls, wget, etc. What we need are some sinks. A couple of useful sinks would be:

• A progress bar. It would read from STDIN and write to STDOUT and show a window that counted the number of bytes that had gone through it as well as having a percent complete, if known.
• A GUI less program that would allow the user to page through the output. It could understand columns.
• A multi-pipe sink that would show several pipelines. This could also be a passthough allowing the user to watch data.

Then we need a way to keep track of a pipeline and to be able to reuse it, like a bash script. The gui pipe building tool could support this. It should also be able to be in a pipeline itself, allowing the user to create a pipeline from the output of another pipeline.

The GUI should also allow for adding of sinks to a running program. For instance, if you have a pipe running, you could insert a tee into it while it was running. The tee could then be connected to a progress bar allowing you to see how much data was flowing without interupting the pipe.

Also, it would mean a need to move to open, simplier structures for data. The same document can be stored in XML as in some propietary Microsoft format.

So how to create a complex document with imbedded graphics, spreadsheets, whatever? Use the multipipe displayer and create a pipe for each element to be displayed. One pipe could simply be a file, treated as an image. Another could be text. Yet another could be a complex pipe that pulls data from a speadsheet application. The multipipe displayer is capable of applying filters to regions. So it doesn't need to know how to resize an image, but is does know how to apply a filter to the image source pipe that does know how to resize it. Same with fonts, and everything else. The displayer will then output the entire things so that is can be saved as a single document or as a the set of input pipes. For output, there could be an HTML filter or an XML filter or a Postscript filter or a PDF filter.

By using small and simple tools, any arbitrarily complex system could be created, using only the resources required. Contrast this with the current bloat mentality of put everything in that could possibly be used, even if only 1% of the population would ever use it.