3 ms·
What if the client is fully in the browser and the server is simply serving up JSON or XML? Seems like as long as the verbs and nouns served are appropriate, yo
by cpr 18y ago
What if the client is fully in the browser and the server is simply serving up JSON or XML? Seems like as long as the verbs and nouns served are appropriate, you've got a good RESTian solution in the end, with interactive (browser client) and batch (server) interfaces available.
- lkcl 18y agothat's precisely the architecture that i use for the two web sites i've done, so far, and i'm currently working on two more. the only exception to the use of JSON has to be the uploading of files, where you're forced to use HTTP POST. and, for the same reason, when _downloading_ the file (e.g. an Image, a PDF) i don't use JSON, i use an HTTP GET. the reason for using the HTTP GET instead of JSON is because it's necessary to set a "Content-Type" header, in order to get the browser to load the file (Image etc.) correctly. other than file upload / download, yes, you can design your Pyjamas / GWT / RubyJS-rwt web site as a totally-compiled-to-javascript site that loads data exclusively using JSONRPC.
- hxa7241 18y agoBut this doesn't address the explicit, simple, standardisation of app/interaction structure. If it is defined in a full procedural language, it is obscure and un-manipulable. The application structure should be moved as much as possible into that JSON, XML, or similar, and standardised. So the browser has a fairly simple and very general app-engine, and everything specific is in a simple, open format. In a sense: turn as much as possible into 'content', including interaction and app intelligence. Then, like other 'content' like movies or music, it is dumb, but infinitely accessible and manipulable.