Reso, odata, oauth2 and nstic

US realty is a political place – and rightly so. And so it was with a non-decision by the so-called RESO group to not endorse the odata approach to data apis. Of course, things had been setup ahead of time so that this non decision will evolve over time into an endorsement. Quite who outside is driving this will be interesting to identify. I already have some ideas. For example, the azure ad graph api comes nicely with oauth and odata, already!

To be honest, the direction being taken is folly; but the least folly of several choices. Competing with the legacy protocol – which is itself a distant ancestor of odata – is going to be hard, however. This will be particularly the case if the legacy protocol, called rets, modernizes its session token and login handshake to now use (quite easily) the oauth2 handshake and its bearer access token. If it also offers a new content type extending those negotiated today to also offer json, oauth/odata is going to have a run for its money – since 80% of what odata advances beyond todays legacy will become available within the rets franework, for a minor refit cost. While others stuggle making odata scale, those using an updated rets+oauth2 might capture the 80% of the interactive, restful uses that really matter. At that point, its game over – once one factors in the re-engineering costs of a native odata query engine doing huge searches.

Of course the simplest oauth server is a gateway, from new to old, for simple, fixed read only search queries – referenced using the odata mechanisms. That toy should take 10m.


About home_pw

Computer Programmer who often does network administration with focus on security servers. Sometimes plays at slot machine programming.
This entry was posted in coding theory. Bookmark the permalink.