It’s said you never want to see how sausage is made because you’ll never eat it. Some people may feel that way about a lot of things, but not about how RESO data standards are created. That process can be downright fascinating.
In Seattle recently, Zillow Group hosted our Transport Workgroup for a two-day intensive drill down on the use of OData (Open Data Protocol) as the fundamental building blocks for taking our RESO Web API to the next level. The group is working on how to give our API all the necessary functionality required to add, update and delete data from MLS systems that implement the RESO Web API.
Tangential to this work is the ability to transport Listing Entry Business Rules using the RESO Web API, allowing machine to machine communication and application of Business Rules for every listing.
Getting to the point in this two-day meeting where we could see the clear path to how we were going to accomplish all this, at times, is a lot like making sausage. It was messy, pulled in a lot of different pieces into the mix, and took a lot of time to get the final ingredients right before our members could consume it. Yet, the entire process was marked throughout with moments of brilliant problem solving by some ridiculously smart people.
Expert guidance
Having an OData expert in the room was the linchpin to this meeting’s success. We invited Mike Pizzo, who is a Software Architect with Microsoft Corporation and, most importantly, is a member and editor of the OData Technical Committee, the body that maintains and creates OData standards managed by OASIS, a not-for-profit consortium that brings people together to agree on intelligent ways to exchange information just as RESO does for the real estate industry.
Mike probably saved the Transport Workgroup several weeks of research. His depth of knowledge enabled him to whiteboard out examples of code solutions, showing what syntax was needed and what was not. But his most critical contributions came near the very end when he helped the group find the right OData solution to the meeting’s main objective.
Looking for a solution
This effort began in earnest at last year’s Austin RESO meeting. RESO members Paul Stusiak and Sergio del Rio asked Josh Darnell, then at FBS, if he could find a way to express real estate business rules through the RESO Web API in a way that would work for both the client and the server.
Josh dived in, scoped out the project, and began reviewing current OData standards (OData 4.0) and the use of Validation Vocabularies as a possible means to satisfy the business rule use cases. When Josh compared the current OData standards to the previous RETS 1.9 Validation Expression standard, he found some shortcomings.
“While it was possible to express some validations in OData, we needed more functionality to support the industry use cases,” Josh said. The good news was that the specification for the next version of OData — OData 4.01 – would offer relief. “It was much closer in parity with our existing business cases,” he added.
Going forward
After an extensive review of OData validations, valuable feedback was provided to the OData committee based on Josh’s work, including the current uses of validation expressions in RETS and the need to perform the same tasks in the Web API.
“There were gaps in the ability of OData 4.01 to fully support our business case,” Josh said, but a breakthrough came at the recent Zillow meeting.
“Mike Pizzo was able to understand our needs and how OData will need to further change to support those needs,” he said. “We can modify our existing Validation Expression language to support our business case and preserve the investment that many people have made in their existing systems while we continue to work with Oasis to add support for these cases in OData,” Josh added.
“The meeting with Oasis in Seattle was valuable. With the help of Mike Pizzo, we were able to outline the direction we need to take in the short term, which is to continue using RETS Validation Expressions for now, as well as in the long term, in building out OData support for our business cases.”
In the meantime, Josh, working with fellow RESO member Rob Larson, have put forward a Rules Resource that will allow people to communicate existing business rules, which will remain compatible once we have a suitable way to express them in OData. “Many thanks to FBS, as it was their generous support that made these reviews possible,” said Josh.
Business Rules and the RESO Web API
Transport Workgroup member Ashish Antal, Director of Technology at MLSListings, Inc., describes how OData 4.01 will enable the RESO Web API to deliver machine to machine business rules once it is implemented.
Ashish explains, “Because RESO is using OData APIs to exchange data from one server to another server, the same transport specification now enables these two machines to communicate the ‘business rules expressions’ through the metadata. This enables the API server to encode all the business rule expressions and attach them to the fields where those Business Rules need to apply.”
The “metadata” Ashish mentions is “descriptive information about a data set, object or resource that helps a recipient understand how the data is formatted.”
Technical how
Ashish breaks it down this way.
“OData APIs have built-in capabilities to allow expressions (that are in the metadata) to be annotated to a field,” he said.
“Which means if you have a field called ‘List Price,’ you can attach an expression to that field that says, ‘List Price must be greater than 0.’ This is a validation expression based on a business rule. This can be applied to the user input form – the screen where the agent enters the listing data. So, if there is another machine that takes the data from the server, the API Client now knows that if any changes are going to be made to the List Price, the user, or agent, must enter a value that is greater than 0.”
“This is a simple example of how the RESO API can be used to transport a rule from one computer to another computer, with the other computer able to parse and apply the rule properly,” he explained.
Two kinds of API needs
In practice, there are two kinds of API Client needs, Ashish notes. “One API Client would simply consume the data and publish it. They don’t care about making changes to that data. The current RESO Web API gives them exactly what they need,” he said.
“The second kind of API Client need typically comes from software vendors or brokerages who are developing their own software. Companies who are creating apps would now have the ability to allow editing of the data from that app, on top of the ability to publish data. So, if they can authenticate and authorize the end user, they can allow the end user to make changes to the listing when the end user is the owner of that listing,” Ashish explained. For brokerages building Upstream functionality, this is crucial.
It also means for developers of mobile apps that they can put in the hands of an agent the power to edit a listing – or even an agent’s profile – all from a smartphone.
An example: “If there was a listing that this agent owns, and the listing goes from ‘on market’ to ‘off market,’ then the agent would have the ability to use that same mobile app to change the status of that listing and communicate that back to the MLS,” Ashish said.
“The app, now that it can understand what the Business Rules are because it has the capabilities built-in, it can apply all the conditions. So, when the agent is making changes, the app can decide whether or not those changes are allowed before sending them over to the server.”
Better data, greater accuracy
One of the additional benefits that Ashish expects to emerge from these efforts is more accurate data and greater confidence in the data that is being received. “When you have a valid return Client working with a sophisticated API server, they will know that the data that is coming to the server is already validated because it has all these checks in place,” he said.
Business Rules themselves are likely to get more attention. Last year, a group of RESO volunteers within the RESO Research and Development Workgroup culminated a two-year effort with a new best practices reference manual (PDF) on Real Estate Business Rules. REBR allows the technical business rules from a “machine” to be expressed in a human consumable (readable) manner.
“We found that while REBR was good for communicating rules between humans, it wasn’t suitable for transport and evaluation between machines,” Josh said, and that’s why the RESO Transport Workgroup is bringing to fruition is the much needed machine to machine business rules communications.
Ashish believes this could lead to better business rules, saying, “Once MLSs realize they have these capabilities to communicate these business rules over to the Client, then some will start improving their Business Rules, by tightening their rules and expressions.”
For now, until OData 4.01 is fully instituted in the fall and beginning of next year with some slight modifications to better support the real estate industry needs specifically, Business Rules can be transported through the current RETS Update validation expression language for the RESO Web API update specification. This helps ensure rapid delivery of this new specification while leveraging technology already built out in some MLS environments.
Doesn’t all of this motivate you to, if you have not yet done so, join a RESO Workgroup or Workgroups? You can check them all out in person at our RESO Fall Conference in Milwaukee in October. Otherwise, see our website at https://www.reso.org/committees-and-workgroups.
