.NET developer with writing an OData wrapper around HubSpot -- 2

Write an OData wrapper for all Read requests that are then made against the HubSpot API and returned. No Create, Update, or Delete operations, just Read (ie cRud). The external OData server written operates as a standard OData server. For all requests, it then queries the appropriate HubSpot API calls to get the desired information and return it. This needs to handle any valid OData read query. The code must be written in C# to .Net Standard 2.0. And is available as both a directly callable library and as an ASP.NET REST server. The directly callable library will be in the form Select(userToken, "$metadata") while the REST service would require a call of [login to view URL]$metadata The REST server needs to support both the API and OAuth forms of authentication to the underlying HubSpot RESY API. The callable library only needs to support the API form of authentication. And for the direct library call, after establishing a connection, it's fine if a token is returned that has to be passed in for every call. The service must handle every object in the HubSpot API. There does not appear to be a call to get this, so this will likely have to be a hard-coded list in the program. To build the metadata, for each object it must get all properties, both standard and custom (user added) ones. (Helpful info here - [login to view URL]) It must also include all associations as OData links. I think you can get all associations with a call to HubSpot. But if not, these can also be hardcoded in lists per object. It must handle all selects including filters, etc. This should be easily translatable into a query of the object in HubSpot as the HubSpot API supports filters on all properties. For the selects, it needs to handle any select that can be passed down in a call to the HubSpot API. If there are filter criteria that exist in OData, but are not supported by the HubSpot API, queries using those filter criteria can return an error. With the addition that count() must be supported, even if that requires in this system to do a full query, then count the rows returned, to return that number.