Response class?

[sckott]

Make a new response class to hold results? Or stick with Faraday::Response object? Benefits of a new class is full control, but sticking with the Faraday::Response builds on all the hard work done already on that gem

[sckott]

@mfenner What is best practice in Ruby with respect to this question? From your point of view, would you rather get back the raw Faraday::Response object or something else? If not the Faraday::Response object, seems a new response class defined in this client would be best, with methods on the response class for parsing, response status, etc.

[mfenner]

See my utility class here: https://github.com/lagotto/lagotto/blob/master/app/models/concerns/networkable.rb. The tricky bit is error handling, as you want to catch them and give a meaningful message back to the user. I use response.body and parse the JSON (or XML) if there is no error.

[mfenner]

In other words, if there is no error you probably are only interested in response.body.

[mfenner]

My utility class for DOIs is here: https://github.com/lagotto/lagotto/blob/master/app/models/concerns/resolvable.rb

[sckott]

Thanks. Right, that is a lot of work for error handling

[mfenner]

You can probably get away with less. But I collected this over time. A simpler version is at https://github.com/crosscite/doi-metadata-search/blob/master/lib/network.rb

[sckott]

Given cursor for paging in the API #14 I think it makes sense to have a class for the response object so that we can maintain state, esp since this cursor approach to paging is esp not very easy for a user to handle manually

[sckott]

Would still be nice to return a hash by default if no errors since users can easily process that as needed

[mfenner]

yes, I like hash as standard response, with an :error attribute if an error occured. Thinking about JSON API, maybe the standard key for a succesful response could be :data.

[sckott]

data is a good idea, haven't had to do that so far as no internal paing, but once that's used, will need to do that when combining results

[mfenner]

haven't thought much about it, but would be interesting to see how much you can propagate API conventions into the processing of the response.

[sckott]

Good idea. will think about that

[sckott]

will need to create a class for maintaining state for using cursor, see #14 , but can still just return hash/array

[sckott]

closing for now, returning hash/array