Create a basic Analyzer class that allows easy specification of what characteristics go into a given type of call.
Given an ApiInteraction (record of an API call) which matches at least one of a set of specific criteria (String, Regexp, block) for its method, path, host, query string, request body, etc., Analyzer should map the call to a unique description. (For instance, POST /me/photos for Facebook would map to "Posting a photo to a user").
How exactly the analyzer would be structured is TBD -- it could be a DSL with specific files that get loaded and parsed, or a more RSpec like set of Ruby classes (with an internal DSL). Also TBD is how to store the analyzed information -- most likely each unique type of call would be a record in an ApiCalls, each of which would contain Title and other information needed to display the call, with a has_many relationship to data from actual calls (that is, result_status and duration, which are needed for aggregation and graphing).
Additional features:
the matchers should be flexible, allowing multiple unique call types to come out of a single matcher (e.g. POST /user/[connection_type] should create different type of call for each connection type -- photo, feed story, link, video, etc.).
Create a basic Analyzer class that allows easy specification of what characteristics go into a given type of call.
Given an ApiInteraction (record of an API call) which matches at least one of a set of specific criteria (String, Regexp, block) for its method, path, host, query string, request body, etc., Analyzer should map the call to a unique description. (For instance, POST /me/photos for Facebook would map to "Posting a photo to a user").
How exactly the analyzer would be structured is TBD -- it could be a DSL with specific files that get loaded and parsed, or a more RSpec like set of Ruby classes (with an internal DSL). Also TBD is how to store the analyzed information -- most likely each unique type of call would be a record in an ApiCalls, each of which would contain Title and other information needed to display the call, with a has_many relationship to data from actual calls (that is, result_status and duration, which are needed for aggregation and graphing).
Additional features: