Saturday, August 1, 2009

Discorvery/Reinventing the Wheel

After much research, I came to the conclusion that JSON is great for
what I want to do except for one thing - binary images. (This research also showed the reason why there are so many 'partial' adoptions of JSON.)

Binary files as fields in JSON objects are especially a problem during a PUT operations. In all the server script languages and in Apache itself, there is access to GET and POST parameters. There is no such mechanism in PUT. One has to write a script to create the boundaries for mulitpart PUTted files in your own application, AND in script for manually dividing up the body of the put based on the boundaries to claim them on the SERVER. In scripting languages, this is very slow.

Of course, it could be sent as base64 encoded strings, which is what
the designer of JSON had in mind, but that is EVEN SLOWER than scanning for boundary markers in a POST style body using a script language. (These are all assumptions on my part, not testing done.)

So my approach is simliar to Amazon's S3 storage server:
http://www.anyexample.com/programming/php/uploading_files_to_amazon_s... and to Yahoo's email attachment option, (UPlaid files for storage and virus scan, then send body of email)

I will have the user POST binary files to a separate SUB domain, using Apache-LIght (a seperate process on a seperate, very fast server), and the server will return a 'bucket', or random file name, (protected by permission headers in between client and host , i.e, header cookies).

The application on a browser or other (IPhone non browser app for
example) Will then populate the fileds of the JSON with the returned
server/filename, as well as the usual binary file related stuff, i.e. title, type, etc.

Applications GETting JSON objects, or PUTting Objects will get or send binary files the same way.

And also, I don't like the semantics of PUTting to originate a JSON
object. So I will be restricting PUT to the Update only of standard
CRUD, (Create, Read, Update, Delete). I don't want users setting
primary key fields.

So, I hope this saves other people some effort that I went through.

The next post, sometime today, will explain what I found out about PUT/DELETE methods in HTTP on Apache @ A2Hosting (I use them because of good support and Postgres databases). To properly use REST, and not use kludgy URLs using both POST and GET values at the same time, (totally doable, but not clean), PUT and DELETE are necessary complements to the standard POST and GET methods.

No comments:

Post a Comment