Interesting idea. Some notes / comments / questions on the posted code (in no particular order): * setting up a separate routing namespace for the API would cl

Interesting idea. Some notes / comments / questions on the posted code (in no particular order): * setting up a separate routing namespace for the API would clean up a number of things. In particular, it would make the web-only actions much clearer; calling respond_with with a JSON error payload and then relying on it to render the template (as done in OnionsController#index, for instance) is terribly confusing on a first read. * does logging in actually set session[:UserKey]? It doesn't appear to, but that would make returning users unable to decrypt their existing onions. * I really, really hope that isn't your actual session secret in config/initializers/secret_token.rb. More info on why this is bad and how to fix it here: http://blog.phusion.nl/2013/01/04/securing-the-rails-session-secret/ http://blog.phusion.nl/2013/01/04/securing-the-rails-session... * The encryption code in OnionsController would be better suited in the Onion model, especially since the decryption code is already there. * the API for adding onions (OnionsController#addOnion) does not encrypt the data before storing it. Is this intentional? * every action that modifies onions creates a new session. From the way that new_session works, I'm guessing this is to provide "session expiration" that's reset every time a user changes something. Would updating the timestamp on the user's existing Session accomplish the same thing, or have I missed something? Some more code-review oriented notes: * Some of your class methods in the models would be clearer as instance methods - for instance, both account_exists and pass_is_good take the hashed username as an argument and find the corresponding Account object. pass_is_good could be an instance method on Account. As another example, the code inside the loop in decrypted_onions_with_key could be an Onion instance method (telling an Onion object to decrypt itself vs. doing it externally). * the comment character in Ruby is #, not surrounding things in / symbols (which creates a Regexp literal). In most cases (config/routes.rb, for instance) this happens to not cause problems - but it's still not a good habit to get into. * some style notes: none of these affect the operation of your program, but they will affect how efficiently other developers read your code and work with it. First, pick a tab setting in your editor of choice and stick with it. The "Ruby standard" is 2 spaces, but if you prefer something else at least be consistent. Second, check out some of the Ruby style guides regarding naming. CapitalizedCamelCase is makes for somewhat odd-looking database column names.