The Genius API this crate wraps sucks. It is poorly documented, and doesn't indicate some of the weird cases that can possibly happen, and what can't happen. It's hard to hit a moving target, and this crate admirably attempts to. The crate also seems to map well to the perceived invariants in Genius API responses, when it comes to the format of said responses.
However, the methods in this crate papers over that complexity in a way that doesn't directly map to what the responses actually provide. Particularly, this crate's types liberally use Option when a field in a result could simply not be there, but the methods assume those fields will be. The use of Option in an intermediary BlobResponse is the current work around, but serde and Rust provide other ways of dealing with this issue.
The first commit of this draft PR simply documents the invariants this crate relies on by replacing unwrap methods with expect methods that include messages documenting the invariants relied upon. However, a better approach may be to rethink the BlobResponse type and instead use an enum that, in combination with serde, could more closely map to the same invariants. The types should map as closely as possible to the results being parsed.
The Genius API this crate wraps sucks. It is poorly documented, and doesn't indicate some of the weird cases that can possibly happen, and what can't happen. It's hard to hit a moving target, and this crate admirably attempts to. The crate also seems to map well to the perceived invariants in Genius API responses, when it comes to the format of said responses.
However, the methods in this crate papers over that complexity in a way that doesn't directly map to what the responses actually provide. Particularly, this crate's types liberally use
Optionwhen a field in a result could simply not be there, but the methods assume those fields will be. The use ofOptionin an intermediaryBlobResponseis the current work around, butserdeand Rust provide other ways of dealing with this issue.The first commit of this draft PR simply documents the invariants this crate relies on by replacing
unwrapmethods withexpectmethods that include messages documenting the invariants relied upon. However, a better approach may be to rethink theBlobResponsetype and instead use an enum that, in combination withserde, could more closely map to the same invariants. The types should map as closely as possible to the results being parsed.