Other OData REST APIs as EntitySet drivers? about lodata HOT 4 CLOSED

Hi @abbluiz, I think there are two ways this could be implemented, depending on your use case.

Are you describing a kind of discovery service where you can just hit one central OData service and see and call all the model endpoints from all your services by accessing the central service, as if it were one big service (even though it's really many separate microservices). This is definitely worth implementing in core Lodata at a deeper layer than entity sets, as then you could expose operations, singletons etc. as well.

You could then do nifty things like a batch request that could operate across many services.

Or if your case is that you have existing third party OData services (eg from Restier) that you wanted to expose as only an entity set (and related types). You're right that to mount a specific entity set from another OData service the way to do it would write a driver. I think if you wanted to really just forward the incoming path and all its query parameters etc. onto the remote that would be quite straightforward to write as a generic ODataEntitySet class.

from lodata.

Thanks for the thorough response @27pchrisl. As I am new to OData, I am guessing whether there is some part of the specification that deals with this kind of functionality or it's just left in the open. My approach is using many Laravel APIs as different OData servers, specifically 2 or more that would probably be consulted a lot of times because it would store User data and other common data that is reused in other, more specific APIs, all of this guarded by OAuth 2.0 in a separate server. I am still working on a OAuth 2.0 server that would not use OData, but will work my way through the other APIs. I will continue to study these possibilities. Would love to know if you have any pointers on resources I could read or something like that. I will be closing this as a issue though.

from lodata.

The spec to look at is the CSDL one.

It's certainly clear from a schema perspective that you can include as much namespaced information as you like from many sources: https://docs.oasis-open.org/odata/odata-csdl-xml/v4.01/odata-csdl-xml-v4.01.html#sec_Schema

However it's less clear when it comes to the concrete data like entity sets. https://docs.oasis-open.org/odata/odata-csdl-xml/v4.01/odata-csdl-xml-v4.01.html#sec_EntityContainer
You can only have one entity container, and the names of the sets and operations are simple identifiers (non-namespaced) and are unique.

Possibly the solution is to have more of a traditional proxy path system where you had a web server that didn't need to understand OData, but could proxy paths to different services. For example:

http://core.microservices.net/ms1/odata/Data -> Proxy passed to microservice 1
http://core.microservices.net/ms2/odata/Data -> Proxy passed to microservice 2

OData also suggests that clients SHOULD understand redirects. So you could serve redirects instead of data from this proxying server, and the client would cache the redirect location and use that for further requests. Technically it should be able to do this with metadata discovery, you ask for http://core.microservices.net/ms1/odata/$metadata, you're redirected to http://ms1.microservices.net/odata/$metadata, and the URLs in that document are accurate for ms1.

Thinking about it, this might be the best way to handle this as a Lodata feature. Rather than trying to make a single OData service of microservices, just provide functionality that assists OData clients with service discovery via programmatically resolved redirects. Then you could do clever things with load balancing, blue/green deployments, region-awareness etc.

from lodata.

In fact interoperable OData clients MUST support redirects: https://docs.oasis-open.org/odata/odata/v4.01/os/part1-protocol/odata-v4.01-os-part1-protocol.html#sec_InteroperableODataClients

from lodata.