Is odata protocol a good standard for REST services?

3
votes

We are looking at using Odata protocol as a REST standard for our services. Based on my research I don't see widespread adoption of Odata which was initiated by MS in 2007 but now it is open since 2014. I even saw an article which point that big players like Netflix and Ebay moved out of it http://www.ben-morris.com/netflix-has-abandoned-odata-does-the-standard-have-a-future-without-an-ecosystem/ .

I have found following limitations based on search on the internet and also previously asked questions on odata (I apologize in advance if the limitations I am mentioning are not correct):

  1. Not very widespread adoption. The APIs offered by AMZ (other cloud platforms) etc do not support odata for most of their services.
  2. Not very many open source projects using odata .
  3. There is only one open source project Apache Olingo which implements odata 2.0 but that too does not supports JPA in odata 4.0. Based on the activity on the email list , this does not appear to be very active and does not seems to widely adopted. Another open source project odata4j on code.google has been archived.
  4. It does not supports signature as parameter which are used to validate if the API call is valid or not .
  5. It does not supports caching
  6. Some other limitations are mentioned in OData with ServiceStack?

Can you guys please share your experiences with Odata that will help us make the right decision?

1
jpaodata

1 Answers

2
votes

Having implemented an OData based solution for a reporting system with a C# backend and Excel as the client I have to say iv'e been very happy with what Iv'e seen. In .Net based projects - OData is easy, reliable and fast to develop. The querying capabilities are very impressive, the data (returned as XML) can be easily handled by any XML compliant client application or component which is great.

Having said that - when approaching a large scale project - you probably have considerations that are different than mine (most of which you wrote above).

OData is indeed not very wide spread. Future support IS an important consideration and providers of OData compliant technologies may drop support for OData if they see it's not being used. Still - I believe it's not going to go away any time soon. The same goes for Open Source projects - it's reflected by the level of adoption of OData in the market.

Security is a big consideration when it comes to any data consuming app/service. Here - I would not relay on any blackbox solution. I keep the security aspect separated from my business logic , handled by a handler in a separate layer (before the business logic component even starts to handle the request). Some people will probably offer other approaches which may fit their needs better. There is a lot that can be written about securing OData service. You should do some more research about this as it is a big topic.

Caching is a subject different from data consumption, so saying OData lacks support for caching is like saying "my car cannot make coffee" :)
Caching is (mostly) subject to the data consumption patterns of the users so you should examine what should get cached and what shouldn't. There are tons of caching components you can use.

The limitations you wrote about should be taken into account in relation to the project you are involved right now. it's difficult to debate on weather it promotes bad practice or not but there are is a price you pay when you use a blackbox component like MS's OData.

To summarize - I OData shortened dev time for my considerably when I developed small scale applications but when it comes to large scale , enterprise level apps - It wouldn't be my first choice and I'm not sure I'd recommend it to others unless OData's benefits for the specific project were big an necesasry.

Good luck!