If your images are not too large, putting them in the database with a RoR :binary type makes a lot of sense. If you have database replicas, the images get copied for free to the other sites, there's no concern about orphaned or widowed images, and the atomic transaction issues become far simpler.
On the other hand, Nessence is right that Base64, as with any encoding layer, does add network, memory and CPU load to the transactions. If network bandwidth is your top issue, make sure your web service accepts and offers deflate/gzip compressed connections. This will reduce the cost of the Base64 data on the network layer, albeit at the cost of even more memory and CPU load.
These are architectural issues that should be discussed with your team and/or client.
Finally, let me give you a heads up about RoR's XML REST support. The Rails :binary
database type will become <object type="binary" encoding="base64">...</object>
XML objects when you render to XML using code like this from the default scaffolding:
def show
@myobject = MyObject.find(:id)
respond_to do |format|
format.xml { render => @myobject }
end
end
This works great for GET operations, and the PUT and POST operations are about as easy to write. The catch is the Rails PUT and POST operations don't accept the same tags. This is because the from_xml
code does not interpret the type="binary"
tag, but instead looks for type="binaryBase64"
. There is a bug with a patch at the Rails lighthouse site to correct this.