One of the most exciting things about new technology is watching all the various ways companies leverage innovations. Web APIs (Application Programming Interfaces), pioneered by Salesforce in 2000, continue to drive innovation in all industries, including real estate.
The RESO Web API is not immune to innovation when it comes to new applications. Even our Workgroups are finding new ways to not only improve our Web API, but also make it even more robust.
However, new technology can often be misunderstood and is subject to mischaracterizations. There appears to be a common belief that real estate data accessible through the RESO Web API can’t be replicated. Is that fact or fiction?
Turns out it is total fiction. RESO Web API replication is not only possible, but Homes.com is already doing it!
Shaun York, Executive Director of Technology at Homes Media Solutions and active RESO Transport Workgroup member, explains that Homes.com is replicating listing information from approved partners through the RESO Web API standard.
“Replicating this data is a critical component of our service offering that allows Homes.com to meet the high demands of buyer search interests while also offering robust toolsets to our agent and offices managing the real estate transaction experience,” Shaun explains.
The benefits? For data providers, Shaun says, “It can be as simple as cost savings by allowing those providing the rich application experiences to assume the infrastructure requirements of their products.”
“Replication also allows for deep innovation by providing hosted access to listing data, adding far greater flexibility than may be covered or out of scope by the standard,” he adds.
Then why the confusion?
Perhaps no one is closer to the subject of RESO Web API Replication than RESO’s own Paul Stusiak. A former RESO Board member and President and Owner of Falcon Technologies Corporation, Paul is Co-Chair of our Transport Workgroup.
He gives a breakdown of the topic:
“Data replication is a process to extract and load records from one system to another. Often a transformation is applied between the extract and load to modify or add information to the record.”
Most data standards provide basic replication interfaces driven by a modification timestamp that tells the requesting system what the record set is at a specific point in time. This is a requirement of the RESO Web API.
The workflow typically follows something similar to this:
- Request all records at this point in time.
- Work around the limitations on maximum records imposed by the implementing system to obtain all these records.
- Perform any transforms.
- Load the records into the system.
- Note the timestamp.
- Make subsequent requests to get the changed records from the initial point in time and the current time.
- Load the changed records into the system.
- Perform a [resolution/dump-and-reload/other process] on a periodic basis to resolve differences between the main record store and the replicated store.
As Paul notes, the RESO Web API fully supports this type of workflow. He goes on to explain:
“This simple form of replication is implemented by all major OData systems that are in the field, including those from SAP and Microsoft. Enhancements can be added to the RESO Web API to provide a ‘removed’ record endpoint to allow the replicating system to ask for records that are no longer visible to their role/rights for any period without changes to the existing RESO Web API. This is not part of the standard but is under discussion to explicitly add this to the standard to enforce this enhancement.”
Moreover, data distributors also can “control” aspects of replication. For example, FBS through its Spark API platform is able for its MLS clients to prohibit replication by default for real estate products that need access to MLS data but that don’t really need to replicate the actual data, but then enable it for those that do need to replicate the data for production functionality. The API provides real-time access where for many products they don’t have to replicate – like they did with RETS – for the same level of functionality, which does minimize the amount of data copied and redistributed.
So why is there this pervasive belief that the RESO Web API can’t be replicated?
Paul says it’s probably because technology companies are telling their customers they can’t provide it.
“The only reason that a vendor may state that they do not support replication is that they have not invested sufficiently in the infrastructure to support the Web API,” he said. “If they can’t support replication, they won’t be able to support real-time queries of the RESO Web API.”
Shaun adds that another reason there’s a lack of understanding about RESO Web API Replication stems from the original mission of the RESO Web API: “to fulfill real-time, easy-to-query access to the listing data origin.”
“With such a focus, the replication use case was downplayed in the development of the new requirements,” Shaun said. “However, the products of developing this standard also apply to replication, and it’s in the industry’s best interest to promote easy adoption for all use cases through this well documented, secure, and standards-driven resource.”
The bottom line is fact: RESO Web API Replication is real and ready to roll. If you want to learn more about the RESO Web API and have met with leading real estate industry engineers who can answer your question directly about replication, register for the RESO Spring Conference – It’s Game on for Data Standards – in Denver, April 24-26 at the game-themed The Curtis Hotel at reso.org/spring-mtg. RESO members can save $100 off the regular registration price of $450, and non-members can save $150 off the regular registration price of $600 by registering soon – and before it sells out!
Jeremy Crawford is the CEO of Real Estate Standards Organization, or RESO, the organization responsible for the creation, promotion, adoption, and utilization of standards to drive efficiency throughout the real estate industry.
