Text

· · to read

Faraday

Faraday is an high-level HTTP client library with middleware support, and support for multiple low-level HTTP client libraries. It can be used just by adding it to the Gemfile and running bundle install, just like RestClient can. Or, a different library can be added to the Gemfile and then used through one of its adapters.

Faraday Middleware

The faraday_middleware library, which was started by Wynn Netherland and has been maintained by Erik Michaels-Ober, contains a bunch of middlewares for authentication, response parsing, and convenient hash objects.

Faraday Stack

Faraday Stack is a pretty generic yet convenient API client. It encodes JSON, parses XML and JSON, follows redirects, and raises errors. In short, it works like many expect custom API clients to work, yet it can be used anywhere, just by specifying the domain. It doesn’t include authentication, which ships with many API clients, but that can be added easily by looking at the source for the stack and adding authentication from another library into it. It’s better than many custom API clients, so if an API client is the slightest bit frustrating, it may be a good idea to use faraday_stack instead.

I really like Faraday, because it lets me choose which HTTP library I’m going to use, which is different between Ruby and JRuby. I often use Faraday by itself even when a custom API client is available. I also will use it in irb (next time, pry) instead of curl at times.

Repositoryfaraday
Ownertechnoweenie
Repositoryfaraday_middleware
Ownerpengwynn
Repositoryfaraday-stack
Ownermislav
Text

· · to read

I’m working on a plugin for displaying infoboxes for URLs called Resource Infobox. The interface is a shortcode with a single url property. To include an infobox, use an expression like the following:

[resource-infobox url="https://github.com/benatkin/wordpress-resource-infobox"]

This will show an Infobox with some basic information:

Repositorywordpress-resource-infobox
Ownerbenatkin

Examples of Infoboxes include those on Wikipedia, in the upper-right corner of pages, and the old Crunchbase ones I saw on TechCrunch:

The neat thing about the ones built by this WordPress Plugin is that it renders based on some JSON rules. The current rule file has two resource types, GitHub Repositories and GitHub Users. These are not limited to GitHub, though; with the current implementation they could be written for twitter, Crunchbase, and any URL that has straightforward mapping from the HTML url to the JSON url. Here are the current rules:

{
  "github": {
    "repository": {
      "url": "https://github.com/:owner/:repo",
      "api_url": "http://github.com/api/v2/json/repos/show/:owner/:repo",
      "fields": [
        {
          "label": "Repository",
          "param": "repo",
          "url": "https://github.com/:owner/:repo/"
        },
        {
          "label": "Owner",
          "param": "owner",
          "url": "https://github.com/:owner/"
        },
        {
          "label": "Last Commit",
          "path": "repository/pushed_at",
          "type": "date",
          "format": "Y-m-d"
        },
        {
          "label": "Watchers",
          "path": "repository/watchers"
        }
      ]
    },
    "user": {
      "url": "https://github.com/:username",
      "api_url": "http://github.com/api/v2/json/user/show/:username",
      "fields": [
        {
          "label": "Username",
          "param": "username",
          "url": "https://github.com/:username/"
        },
        {
          "label": "Followers",
          "path": "user/followers_count"
        },
        {
          "label": "Respositories",
          "path": "user/public_repo_count"
        }
      ]
    }
  }
}

It’s a JSON DSL inspired by the DSL for Django’s admin interface. It has few features now, but following Django’s lead, it can have more features added to it while retaining its essence. The nice thing about using a JSON DSL rather than custom code is that it can easily be validated, and due to its declarative nature, XSS attacks and other undesired behavior can be avoided. It uses WordPress’s esc_attr and esc_url functions to render strings.

I’d love feedback on this. My goals for it include:

  • Caching (WP Total Cache greatly reduces requests to GitHub’s API on this page)
  • Adding more resource types
  • Adding more field types
  • Adding more display customization
  • Adding instructions for using code from this plugin as a base for other Infobox embedding plugins
  • Improving the resource type DSL
  • Building an editor for creating custom resource types
  • Supporting grabbing a resource type definition based on a custom header of a resource (like X-Infobox-Resource-Type)

I’d also like to make this work with more than just WordPress.