Finally Out from Under a Significant Update
I've been working pretty feverishly the last several days on getting my market data server updated with a new API from one of my data vendors. It's been a significant update because of the fact that in this new API they have implemented (and forced us to enforce) login validation and data permissioning. I don't begrudge them the validation and permissioning because it's their bread-and-butter, and it's up to us to decide if it's too much to deal with, but it's the way in which they are doing it that's a real pain.
Based on experience, exchanges charge fees to see their data. Seems reasonable. But they don't really care if you see 1 instrument's price 1000 times in a day, or 1000 instrument's price 1 times a day - or even if you only see 1 instrument's price 1 time a day - it's still the same price. So the permissioning for standard exchange fee-liability is by exchange. Very reasonable.
Given this, we should be able to have a list of valid exchanges for an individual user and then check each instrument for it's exchange and be done. It would mean that we'd have on the order of a few dozen exchanges per user - a very manageable set. But this vendor isn't like that - they want to be able to know exactly what instruments you're asking for, so you have to permission the data at the instrument level. This, too, isn't horrible, but it does mean that instead of having a few dozen things to track for a user, you now have upwards of a few hundred or more. It's still possible, just a lot more work to do with each request.
Then there's the way they do the permissioining... a user has a list of entitlements, and each instrument has a list of entitlements and we need to find a common entitlement between them for the user to see the instrument's data. Why not have a single ID for a user - or an instrument? Why have lists? I'm sure you can have the degenerative case of one item in a list, but from the looks of things, that's not the way it's going. Just really odd. Not impossible to work with, but odd.
So it feels good to be out from under that weight. It's all working, and we'll be able to move to the verification phase with the vendor (certainly understandable) and then on to the roll-out to production.