regjai shaneequa maedock

0 views

Skip to first unread message

Chanelle Kirksey

unread,

Aug 2, 2024, 10:41:19 AM8/2/24

to glasutogre

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 -morris.com/netflix-has-abandoned-odata-does-the-standard-have-a-future-without-an-ecosystem/ .

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.

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.

Feign is a declarative web service client. It makes writing web service clients easier. To use Feign create an interface and annotate it. It has pluggable annotation support including Feign annotations and JAX-RS annotations. Feign also supports pluggable encoders and decoders. Spring Cloud adds support for Spring MVC annotations and for using the same HttpMessageConverters used by default in Spring Web. Spring Cloud integrates Ribbon and Eureka to provide a load balanced http client when using Feign.

To include Feign in your project use the starter with group org.springframework.cloudand artifact id spring-cloud-starter-openfeign. See the Spring Cloud Project pagefor details on setting up your build system with the current Spring Cloud Release Train.

In the @FeignClient annotation the String value ("stores" above) isan arbitrary client name, which is used to create a Ribbon loadbalancer (see below for details of Ribbonsupport). You can also specify a URL using the url attribute(absolute value or just a hostname). The name of the bean in theapplication context is the fully qualified name of the interface.To specify your own alias value you can use the qualifier valueof the @FeignClient annotation.

FooConfiguration does not need to be annotated with @Configuration. However, if it is, then take care to exclude it from any @ComponentScan that would otherwise include this configuration as it will become the default source for feign.Decoder, feign.Encoder, feign.Contract, etc., when specified. This can be avoided by putting it in a separate, non-overlapping package from any @ComponentScan or @SpringBootApplication, or it can be explicitly excluded in @ComponentScan.

The OkHttpClient and ApacheHttpClient feign clients can be used by setting feign.okhttp.enabled or feign.httpclient.enabled to true, respectively, and having them on the classpath.You can customize the HTTP client used by providing a bean of either ClosableHttpClient when using Apache or OkHttpClient whe using OK HTTP.

Default configurations can be specified in the @EnableFeignClients attribute defaultConfiguration in a similar manner as described above. The difference is that this configuration will apply to all feign clients.

If we create both @Configuration bean and configuration properties, configuration properties will win.It will override @Configuration values. But if you want to change the priority to @Configuration,you can change feign.client.default-to-properties to false.

In some cases it might be necessary to customize your Feign Clients in a way that is notpossible using the methods above. In this case you can create Clients using theFeign Builder API. Below is an examplewhich creates two Feign Clients with the same interface but configures each one witha separate request interceptor.

The Feign Contract object defines what annotations and values are valid on interfaces. Theautowired Contract bean provides supports for SpringMVC annotations, instead ofthe default Feign native annotations.

If Hystrix is on the classpath and feign.hystrix.enabled=true, Feign will wrap all methods with a circuit breaker. Returning a com.netflix.hystrix.HystrixCommand is also available. This lets you use reactive patterns (with a call to .toObservable() or .observe() or asynchronous use (with a call to .queue()).

Prior to the Spring Cloud Dalston release, if Hystrix was on the classpath Feign would have wrappedall methods in a circuit breaker by default. This default behavior was changed in Spring Cloud Dalston infavor for an opt-in approach.

Hystrix supports the notion of a fallback: a default code path that is executed when they circuit is open or there is an error. To enable fallbacks for a given @FeignClient set the fallback attribute to the class name that implements the fallback. You also need to declare your implementation as a Spring bean.

There is a limitation with the implementation of fallbacks in Feign and how Hystrix fallbacks work. Fallbacks are currently not supported for methods that return com.netflix.hystrix.HystrixCommand and rx.Observable.

A logger is created for each Feign client created. By default the name of the logger is the full class name of the interface used to create the Feign client. Feign logging only responds to the DEBUG level.