Configurable transport layer

[PandaWhisperer]

Summary

The current version of the gem uses Typhoeus to handle HTTP connections, which is not only awkward to spell (I've already mis-spelled it at least 3 times while writing this issue), but may or may not be awkward to install on some systems since it requires a native extension.

Furthermore, since OData is a pure application-layer protocol, this gem should make as little assumptions as possible about the transport layer. Using Faraday instead of Typhoeus would give users the ability to choose their own HTTP backend (with Typhoeus still remaining an option).

Details

The biggest issue to think about is how to allow configuring the transport layer. Currently, the only possible configuration is by passing in options for Typhoeus on Service.new, which would probably be severely limiting (and awkward) when using Faraday.

Probably the best way to go would be by allowing a block to be passed, which receives a Faraday connection as parameter and can then be customized by adding additional middleware. For instance:

OData4::Service.open('http://services.odata.org/V4/OData/OData.svc', name: 'ODataDemo') do |conn|
  conn.basic_auth 'username', 'password' # or conn.token_auth('<auth_token>')
  conn.response :logger # Add request logging
  conn.adapter :typhoeus
end

However, some behaviors (such as custom headers), must be passed to the request, not the connection, so we'll probably still require a special key in the options hash.

[natemacinnes]

I have swapped out Typheous with Faraday on my fork. You can take a look at my faraday-feature branch if you like. Still need to swap out references to Typheous and add more options to requests, but for now all tests pass. Still need to add tests for Entity creation and updates though.

[natemacinnes]

Additionally, Faraday does not support the Typheous version (Typheous::Easy) that the original OData uses. I was also unable to create entities on MS Dynamics 365 using Typheous::Easy, but it worked without any changes with Faraday and the default Net::HTTP adapter. Changes still need to be made to handle timeouts, Faraday raises an error and the response no longer needs to be verified for a timeout.

[PandaWhisperer]

Hi @natemacinnes, I apologize that I only saw your messages now. My notification emails must have been filtered out as spam or something.

I actually implemented this feature myself recently. Starting with version 0.9.0, this gem is using Faraday as transport layer, and you can configure the connection either by passing a block to the constructor (which yields the Faraday::Connection), or you can set up a connection yourself and pass it to the constructor in place of the service URL (the connection must be set up with a URL prefix for this to work).

This is quite neat as Faraday's middleware stack lets you do things like setting up a connection that will automatically authenticate requests against another server (which I'm doing in reso_web_api).

Please note that I've recently renamed the gem to frodata, and I will be continuing development there. However, this repo will stay online in order to preserve history.

[natemacinnes]

Again, no worries. I think my notifications were also not coming into my inbox either and it has been a busy last month. Best of luck, and I like the new gem name and fro inspo ;)