Bug 421488

Description Mark Macdonald 2013-11-11 17:15:22 EST

The REST API used for sites is too complex for our typical needs. The 'mappings' table basically describes a freeform mapping of site paths to workspace resources or URLs. It is flexible, but hard to author and validate. It should be more restrictive and tailored to specific use cases.

I.e. for a given remote path, there are basically 3 actions the server can take:

  i). Serve up a resource from the workspace.
This is the typical case for testing simple static websites, and doing plugin development.

 ii). Take some action by invoking one of the Orion rest APIs.
This case is important for self-hosting. Requests are handled by sending the request to a servlet. For example, saving a file invokes the /file API, Git operations are handled by /git, etc. Some rewriting of URLs is also involved, so that resource locations referring to the "outer" server appear to be located on the hosted site instead.

iii). Act as a proxy for a remote resource.
This is rarely used. For example, a remote service like http://google.com/search?q={...} could be proxied as http://[some orion site]/googleSearch, allowing scripts to POST to it without violating the same origin policy.


Currently case (ii) is implemented on top of (iii): forwarding a request to a servlet at /{api} is achieved by proxying it to "http://localhost:xxxx/{api}", where 'xxxx' is the port the server is listening on. It's basically a hack for the server to talk to itself. This is brittle, and requires exposing an internal port to the user, which they should never see.

I propose a simpler site API with explicit support for (i) and (ii), and support for (iii) removed entirely.