3

I've been tasked to create a mobile application as well as an accompanying website. Both the application and website will interact with the same database. To make things easy, I figure creating an API would be best that way I can separate it out from the mobile application and website.

Would this be the preferable method? I'm thinking Sinatra would be best for this situation. I'm using Ruby on Rails for the website but feel it would be overkill for the API.

I just want to validate my thoughts regarding this issue.

Thanks!

Mike
  • 141
  • 2
  • Couldn't you simply use rails "format" feature ? This allows you to return plain html for web browser and only data formatted in json or xml to mobile application that uses the API. Application and browser would use same URL, but the first one with /controller/action/id.xml and the second with the usual /controller/action/id.html (for example) – David Sep 21 '11 at 06:57
  • This is pretty much the most ideal use case for Sinatra I can think of. The API part anyway. – Rig Aug 25 '13 at 03:44

3 Answers3

2

If you're already using Rails, there's isn't much gain in running Sinatra as well. To skip the Rails goodness and get a performance boost, use Metal to serve your API requests.

http://api.rubyonrails.org/classes/ActionController/Metal.html

Benchmark! If you find yourself adding lots of stuff back in just to make it work, you might chew through the performance boost and more.

jimworm
  • 121
  • 3
0

Actually Sinatra itself recommends using it as middleware, e.g. for rails applications.

So I'm guessing it's more a question of which you are most familiar with, Sinatra would be a lightweight approach, but rails could work, too. Choose the one you're most familiar with.

gnat
  • 21,442
  • 29
  • 112
  • 288
robustus
  • 101
  • 1
0

Also have a look at padrino. It is built on top of Sinatra and adds much of the goodness of Rails but without the magic.

Many people love the simplicity and expressiveness of Sinatra but quickly come to miss a great deal of functionality provided by other web frameworks such as Rails when building non-trivial applications.

Our goal with Padrino is to stay true to the core principles of Sinatra while at the same time creating a standard library of tools, helpers and functions that will make Sinatra suitable for increasingly complex applications...

gnat
  • 21,442
  • 29
  • 112
  • 288
froderik
  • 141
  • 3