2

I hope I'm directing this very general question to the right audience. If not, don't hesitate to redirect me elsewhere is possible.

I'm part of an initiative at a large company that is starting its journey towards open business APIs to offer data and new digital services. Our team has examined loads of existing APIs out there, many of them award-winning ones but we have yet to find more than a handful (not even that, actually) that are OData. All are "classic REST".

We do have experience with OData and as an SAP-driven company it's supported out-of-the-box for a majority of our backend consumption already so it would be a logical choice.

I can see problems with OData, such as making it more difficult to control load and it might also be more challenging to create clients for such APIs, depending on one's dev platform. Is it issues like these behind the common design decision to go "classic REST" rather than OData in bublic business APIs?

Would really appreciate a good discussion on this topic, or suggestions to sources with analyses.

Thanks

  • 1
    This is in fact a Q&A site, discussions are not really on-topic. – Martin K Feb 29 '20 at 21:14
5

The wonderful thing about API standards is that you have so many to choose from. A short list of JSON based REST service standards include (but are not limited to):

To answer the question of why it doesn't have wider adoption:

The bottom line is that common toolsets like Swagger are good-enough, discoverable, and self-documenting. Using that tool along with whatever API standard you choose means that it really doesn't matter that much which you choose. The caller has to adapt anyway.

The next thing to consider is the complexity of the standard. OData, unlike its competitors requires specific HTTP headers, and if the example I linked to is typical then you have opaque URLs. Sure there's the capability to generate bindings, but you get that with Swagger. It has the complexity of a formal standard specification (remember SOAP?) but no inherent advantages you can't get elsewhere.

Each standard has it's intended set of problems it is trying to solve. For example HATEOAS returns actions and links that the user is permitted to do on a resource. That can drive the buttonology in your Single Page App (SPA) so that permissions are handled by the service itself--and not embedded in the client code.

In your case, where you have SAP in your infrastructure, and OData is native to that world, it might be the right tool for the job. Just evaluate it on its merits to what it provides your infrastructure, keeping in mind who your intended users are. There's nothing I saw that is inherently bad in my quick perusal of the standard, it's just heavy (maybe not in payload, but definitely in cognitive load).

  • Excellent analysis. Thanks! – Jonas Rembratt Mar 2 '20 at 9:29
  • I mostly agree with the above explanation but isn't OData a widely accepted standard? There are so many consumers that have OData connectors for e.g. BI tools like power BI, excel, tableau etc. I didn't follow the disadvantage of opaque urls but as a standard OData is hard to understand. There isn't good documentation too hence implementing it is painful. – Andy Dufresne Aug 5 '20 at 8:18
  • With all the examples you've provided, it seems as if the chief groups implementing OData are commercial entities with big ticket licensing. Another standard that seems to have even more adoption would be OpenAPI (formerly Swagger). So I stand by my statement. If you have to integrate, then you don't have much choice. However, for integration with your clients, maybe there are better alternatives. – Berin Loritsch Aug 5 '20 at 11:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.