You don’t stumble into RETS without a very specific need. RETS is an XML standard for communicating with real estate multiple listing services. It is commonly used to performing queries against MLS vendor systems.
In the past year, I’ve been focusing on integrating a growing number of MLSs into our main product, Sequoia. I’ve used two different libraries to accomplish the low level interaction with a specific RETS server: RETS4R and more recently LibRETS, using the Ruby bindings. As documentation is scarce, I’d like to provide some insight for the community. First, an overview of the two libraries:
Rets4r (https://github.com/josephholsten/rets4r) is an attempt at a pure Ruby implementation for RETS. The most recent versions use Nokogiri for XML parsing for properties, but REXML for metadata. Rets4r was the library I initially used as the basis for our Generic MLS updater. It’s a solid implementation, and I’ve been able to configure for all the major MLS data providers we use. It uses Ruby’s net/http, which is the only real issue I’ve consistently struggled with. Being a pure Ruby based library, installation is a snap (gem install rets4r).
LibRETS (http://www.crt.realtors.org/projects/rets/librets/) is a C++ implementation of a RETS client from the National Association of Realtors. I’ve just completed rewriting our Generic MLS updater on top of LibRETS using the Ruby bindings. LibRETS is quite a bit more challenging to setup (OS X 10.6 & Ubuntu 10.04). It does seem to be a touch faster for property queries, and is much faster with meta data retrieval. API documentation is only available via the C++ documentation.
With Home Brew, installing LibRETS on OS X is a snap: brew install librets. (If you have multiple versions of Ruby on your system, LibRETS will bind to the default version. Be careful if your using a none default ruby while trying to access LibRETS.) For Ubuntu, I installed as follows
sudo apt-get install libexpat1-dev libcurl3-dev libboost-dev libboost-filesystem-dev cantlr libantlr-dev swig libboost-program-options-dev ruby-dev wget http://www.crt.realtors.org/projects/rets/librets/files/librets-1.5.2.tar.gz tar -zxvf librets-1.5.2.tar.gz cd librets-1.5.2 sudo ln -s `which cantlr` /usr/bin/antlr ./configure --disable-java --disable-perl --enable-fPIC --enable-shared_dependencies --prefix=/usr/bin make sudo make install
Our MLS updater is designed to allows us to connect to a any RETS server, map all columns to our database schematic, and run continuous rolling updates, keeping our MLS data in sync with each data provider. The single largest issue with the initial version written on top of Rets4r was connectivity issues from Ruby’s Net/HTTP library. This resulted in lost connections and malformed XML. LibRETS uses libcurl and builds objects via streaming XML, resulting in its own list of challenges. I’ve been been able to mitigate most of these issues by minimizing the time a connection stays open, and retrying failed requests.
Which one’s better? It’s hard to say, but I’d lean towards LibRETS. The connection is more configurable from a setting perspective. If your MLS RETS server requires a user agent password, RETS4R can handle it, but the implementation is kludgy at best. LibRETS allows you to set the user agent password optionally. Retrieval of metadata is a lot cleaner for LibRETS. RETS4R does provide property data back in an array of hashes, the column being key, something I had to write for LibRETS. Although the documentation for LibRETS is for the C++ API, it’s been very helpful. RETS4R has very limited documentation, but enough to get you up and running on basic searching and displaying of property data. A concern with LibRETS is that the main developers are no longer actively working on the library. I haven’t found any bugs, but I would feel better it was a more actively developed project. RETS4R has a small community, and is on Github.