I’ve worked with this and in the context of the SAP enterprise world and all of its ancient and weird stuff this is quite a step forward.
It is however unfortunate that they choose to use OData which is horrible to work with, and the API itself suffers from common REST inefficiencies such as chattiness.
Another thing that bugged me is that this is not just a reverse proxy towards other SAP SaaS api’s, but an actual abstraction layer on top of those. Which makes me believe this probably won’t scale very well into more complex cases.
The best way to look at this I think, is probably as an API for simple in-house apps at companies which use more than one SAP SaaS solution. At least you won’t be using SOAP anymore ;)
Gosh OData is so poorly designed that the only way something like that can even think that it is relevant is if one or two paper pushers inside a big corporate company will force its devs to use it. And so they did.
I have worked with SAP Gateway for a long time but I don't think it's a major issue that it used OData. Maybe it's because our ABAP developer had a good sense. Compared to the Dynamics CRM it made more sense.
SAP committed itself to oData. With Fiori Elements you can generate UIs from oData endpoints. Their super crappy frontend framework UI5 also integrates with it quite strongly.
Yeah, UI5 is quite a nightmare. Working with OData is a dream with it. I always found it really difficult to make the dreams of designers work with SAPUI5. Hard to customise components or write custom ones.
Keeping in mind you are 45 strong company setup, is your shop seriously getting onboard with this?
And sell own apps within SAP customer base using these APIs?
Building your stuff is one piece.
Really, to sell it within SAP customer base, is battle in itself. Unless you are Accenture, Capgemini, IBM etc.
So even if Graph makes some improvement on technology front, why would a smaller scale shop be willing to build anything if they can’t tap easily into that customer base.
In many relational db implementations OData is a serialization of SQL in a URL. A human factor problem with that is poorly optimized SQL. An architectural problem is that db schema changes break URLs.
Well, there is a balance. In many circumstances, the same service used by different applications may over-fetch or under-fetch data [0]. OData allows the application to describe exactly what they need including things like filtering, ordering and aggregation that might be less efficient to perform on the application side [1]. Having performed the OData.org Basic Tutorial [2] using just curl, I was positively impressed by the concept and simplicity.
> OData allows the application to describe exactly what they need including things like filtering ..
I hear this frequently.
I have _never_ faced the need to have complex set of capabilities (OData) promising to solve a problem that I do not have.
I simply craft my APIs very well.
Did you find twilio, stripe, fb.. use OData out in the open?
When you offer the real choice to API developer, API consumer and they naturally gravitate to OData, then we're talking. You think developers within SAP ecosystem get choice?
Its shoved down their throat.
And this is why I believe SAP Graph team is not really serious about "zero SAP knowledge required" crowd.
It is however unfortunate that they choose to use OData which is horrible to work with, and the API itself suffers from common REST inefficiencies such as chattiness.
Another thing that bugged me is that this is not just a reverse proxy towards other SAP SaaS api’s, but an actual abstraction layer on top of those. Which makes me believe this probably won’t scale very well into more complex cases.
The best way to look at this I think, is probably as an API for simple in-house apps at companies which use more than one SAP SaaS solution. At least you won’t be using SOAP anymore ;)