vzvenyach/permafrast — pull request #11 by TalkingQuickly (2014-09-13 18:27:06+00:00)
Title: Feature/caching

So this one is kind of a big one, it:

* Adds a caching layer (Postgres in production, sqlite in development).
* Changes the API structure.

## Caching Layer

The first time a unique combination of volume, reporter and page is requested, this is cached. All subsequent requests are served from the cache. At the moment there's no cache invalidation but it would be really easy to query against `updated_at` and refresh the data every few days/ weeks depending on if it (ever?) changes.

## Changes to API Structure

Not sure if this is the best/ right approach so let me know if it doesn't work. Logic is that at the moment, the json response is just a direct proxy to the Fastcase one, that means if they change it, anyone consuming the Permafrast api will find their stuff breaks. This changes it to return the following API structure:

```ruby
[
{
volume: "600",
reporter: "F.3d",
page: "642",
url: "https://apps.fastcase.com/Research/Public/ExViewer.aspx?LTID=%2fGLQLe%2fDaGym1PLr4VyFrNW1GRW%2fFszkp5OJNGHvwRPnb22Q5oSdo7jrjk8wbX8Q",
full_citation: "Comcast Corp. v. Fed. Commc'ns Comm'n, 600 F.3d 642 (D.C. Cir., 2010)"
}
]
```

This also means results are returned as an array (although for now it will always only include one item). This leaves flexibility in future for searching multiple results at once.

Might be worth testing this one on a temporary heroku account as I'm guessing the production DB stuff might need some tweaking.