Why Data Dictionary and the RESO Web API are important
This year will be seen at as a watershed moment for real estate technology, after years of fragmentation across MLSs the industry is finally embracing two key standards which will improve the way technology companies consume real estate data. The two standards from the Real Estate Standards Organization (RESO) are called Data Dictionary and the RESO Web API. These two standards will impact every company and technology in the industry, including our real estate API product Rets Rabbit.
In this article I’m going to explain what Data Dictionary and the RESO Web API standard are, why they matter, and why Rets Rabbit is integrating both standards into our product.
What is Data Dictionary?
Data Dictionary is a common data schema whose purpose is to standardize data across multiple MLSs. The idea is that there are common fields for resources across all MLSs (for example ListPrice) that should be named & shared consistently across the country. This will improve importing listings by defining predictable and consistent fields which developers can refer to when creating their technology solutions.
What is the RESO Web API?
The RESO Web API standard is meant to offer a standardized way applications can access real estate information directly using RESTful technology. It can be implemented by MLSs, technology vendors, anyone looking for a modern way to share real estate information across technology platforms. This is meant to be the standard all real estate APIs in the industry should follow. Have a single RESTful API standard will make it easier for developers to build websites and applications using real estate data without having import listing data over RETS (or flat text files).
Why are we supporting Data Dictionary in Rets Rabbit?
Both standards are important and have far ranging implications for our real estate API, Rets Rabbit. First, the move of MLSs to Data Dictionary will vastly improve and simplify our import process. Currently we copy whatever fields we import from the MLS, we don’t map to a common data schema mainly because it’s a complex process that is extremely brittle and difficult to maintain.
Our API is flexible enough to accept fields as they are represented by the MLS without having to map to a common schema. This works most of the time, but the inconsistent fields make it difficult for customers to build searches across multiple MLSs, also coming up with good API documentation and examples data for our customers is difficult because the customer’s MLS data may be different, and finally the dynamic nature of our data structure hampers our ability to tune the API for maximum performance. Data Dictionary gets us pass all of these issues, it’s a no brainer to support it.
Challenges implementing the RESO Web API standard
Making version 2 of the Rets Rabbit API RESO Web API compliant wasn’t as easy of a decision as Data Dictionary. We already have a RESTful API after-all and supporting the RESO Web API would require a complete rewrite.
The RESO Web API is built on OData, which means Rets Rabbit v2 would need to be based on OData too. OData isn’t friendly to implement on a non Microsoft/.NET technology stack and a lot of the open source tools were either out of date with the latest versions or hacked together and not ready for production.
Fortunately our developer Andrew came up with a clever solution to allow us to parse OData queries. I can’t thank him enough for the hard work he put into turn the RESO Web API spec docs into working code.
Advantages to customers by switching to RESO Web API standard
Despite the early challenges, there were several things that convinced me that moving to the RESO Web API was the right decision. First, I firmly believe in the work that RESO is doing to bring standard practices to real estate technology. It would be hypocritical of me to support that work and yet have a proprietary API.
Second, I believe that real estate professionals should have was many choices as possible when choosing their technology tools. We want to make sure if there is a great WordPress plugin, or other piece of software that is RESO Web API complaint that it will work without issue on our API. It means that customers may leave us for a compatible competitor, which is fine, if the only reason customers stay with us is because of vendor lock-in we don’t deserve to be a technology business in the first place.
Real estate professionals should have was many choices as possible when choosing their technology tools.
Finally, the real kicker is that in developing to the RESO Web API spec our API has become better than I could ever have imagined. The filtering mechanism alone allows for the creation of some really expressive and powerful queries. I’m in love running queries on Rets Rabbit v2. V2 is far more powerful than V1 and allows you to write some pretty complex yet understandable queries.
Here are a few examples of the queries:
Getting properties for Listing Agent matching ‘John Doe’:
GET /v2/property?$filter=ListAgentLastName eq 'Doe' and ListAgentFirstName eq 'John'
You can get properties where the listing agent’s last name is either ‘Smith’ or ‘Doe’:
GET /v2/property?$filter=ListAgentLastName eq 'Doe' or ListAgentLastName eq 'Smith'
Get all properties whose listing agent’s first name starts with ‘joh’:
GET /v2/property?$filter=startswith(ListAgentFirstName, 'joh')
Properties listed in June 2016 with a list price between $100K & $200K:
GET /v2/property?$filter=year(ListDate) eq 2016 and month(ListDate) eq 6 and ListPrice ge 100000 and ListPrice le 200000
That’s just a small taste. The biggest benefit of the RESO Web API standard was that all of the API design decisions had already been made, what we needed to do was to implement the design and return the data appropriately.
How to signup for Rets Rabbit v2
V2 of our API is ready for beta customers as we undergo the RESO Web API certification process. If you’re interested in using version 2 of the Rets Rabbit API and ditching IDX for your real estate website or application please contact me.