kartikpatodi
02/24/2018, 5:54 PMrkeazor
02/24/2018, 6:25 PMkartikpatodi
02/24/2018, 6:26 PMkartikpatodi
02/24/2018, 6:27 PMrkeazor
02/24/2018, 7:36 PMrkeazor
02/24/2018, 7:36 PMkartikpatodi
02/24/2018, 7:36 PMkartikpatodi
02/24/2018, 7:37 PMkartikpatodi
02/24/2018, 7:37 PMrcgonzalezf
02/25/2018, 2:00 AMrcgonzalezf
02/25/2018, 2:01 AMgildor
02/25/2018, 5:12 AMgildor
02/25/2018, 5:18 AMkartikpatodi
02/25/2018, 5:18 AMrcgonzalezf
02/27/2018, 5:12 PMX-HTTP-Method-Override: PATCH
, so I just switched the library to Retrofit and thanks to that layer of abstraction that I build, it was a 2 hours taskrcgonzalezf
02/27/2018, 5:14 PMrcgonzalezf
02/27/2018, 5:17 PMgildor
02/28/2018, 1:40 AMI implemented a layer of abstraction that was helping me with Mocks, changing endpointsYes, but with Retrofit API you get this by default. Very abstract way. Abstraction over request and even response
maybe for Java/Android is way betterWhat do you mean? Some people hate annotations and such way to define API, but for me it’s the same as defining any other interface. And in 95% cases you write less code with Retrofit and have much more readable and maintainable API definition. I would like to see “more kotlin way” aka “based on dsl” library, but Fuel is just like any other builder-based rest library (check for example Unirest for Java, very similar to Fuel). For example I can imagine something like Retrofit, where you use dsl instead of annotations, but even in this case you need additional abstraction layer, it’s hard to compete with automatic creation of proxy classes