Add a history endpoint

[invacuo]

• A very basic history endpoint as described in the issue Implement History endpoint #39
• Doesn't yet support all the filters that are described in the documentation provided here https://documenter.getpostman.com/view/2025350/RWaEzAiG#9f1dfdc0-fbe8-4ae5-9209-7f3d649a627c
• Allows retrieving all the historical events or a specific historical event by passing an id
• This closes Implement History endpoint #39 when merged in.

Notes:

• Also decided to alphabetize the order in which we require the files in the spacex.rb file

[coveralls]

Pull Request Test Coverage Report for Build 97

• 36 of 36 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 93:	0.0%
Covered Lines:	781
Relevant Lines:	781

---

💛 - Coveralls

[rodolfobandeira]

Hey @invacuo, Sorry I couldn't review this yet. I'm gonna take a look tonight!

[rodolfobandeira]

I'm OK with it. Feel free to merge it.
Also, I'm gonna think on some ideas to implement all these filters and will let you know.

Thanks @invacuo

[invacuo]

I have a WIP branch for implementing filters. It basically uses an optional params hash that then gets passed on to the SPACEX api endpoint. Faraday does the URL encoding for us. I will push it up later today for you to review.

There are some unanswered questions there like what do we do for capsules endpoint that accepts capsule_serial instead of id. Similar questions for a couple of other endpoints.

[invacuo]

Here you go @rodolfobandeira https://github.com/rodolfobandeira/spacex/compare/master...invacuo:history_with_params?expand=1

[rodolfobandeira]

I don't believe deprecating the version 1.0 right now would be a good idea since we just released. Maybe we can create a workaround like adding an extra optional parameter like a hash. For example:

SPACEX::History.info(4, filters = {}) and filters would be something like: {start_at:, end_at:, etc}

Another idea would be just adding different methods and keep .info as it is. This way we add the new filter feature and don't deprecate the current method.

Cheers!

[invacuo]

Not suggesting deprecating version 1.0 right now. It is just a warning of the upcoming changes in v2 that we will be switching to using keyword arguments instead of positional.

Version 1.0 will work as it is. And it will accept the optional filters hash as you suggested. The code however will also work if someone tries to pass the arguments as keyword arguments.

I also thought about exposing another method which is also not a bad idea. I do like the idea of having just one exposed method better though. What are your thoughts on adding a deprecation warning on .info as we get closer to v2.0?