I'm looking write a webservice. A simple example of how a user will interact with this service is user-signup. A user can hit the service to create an account (if they're mobile). On the other hand, users can login (from a mobile app) to the application using the service. Now this service is for an existing rails application. My plan is to build a sinatra app within this rails app, and mount as a rails engine: this app will interact with my existing rails models to produce/consume the appropriate json. Would this be a good approach? Have anyone tried this before? Thank you.
I have used this approach: Rails w/ Sinatra routes. If you are providing a RESTful api I would also suggest looking at the Sintra-like, api-specific framework Grape. This link shows how to mount Grape inside of a Rails app. Best of luck.
"Premature optimization is the root of all evil."
Only go the Sinatra route if you need speed. For example, your rails app might do a lot of unnecessary computation in the application controller which you want to bypass in a mobile app. Even so, I'd be really sure it eats into response time on the mobile client before I started down the Sinatra path. Shaving off 10 milliseconds in the response time probably isn't worth all the developer time unless you're developing a game or something else which is highly interactive.
Since you've got an existing Rails app, just use Rails. It already has most of the code you need. You just need to write some JSON views. That's a lot simpler and easier to maintain than a parallel Rails/Sinatra stack.
I think you should just get rid of Rails and just forget about it. Just use Sinatra for your app, and just pure Rack whenever you can for your middleware.
Contrary to popular belief, you can easily build large-scale applications with Sinatra, the internals can be organized in any way you want.
Rails is slow. Why not just run something fast for everything? There is absolutely nothing you can't do with Sinatra and pure Rack, it's incredibly flexible.
Related
I'm about to launch a SPA app that I built in VueJS but I'm worried about how exposed my API is. Anyone with access to the app could easily just download all of the data I have running through my RESTful API. The API is protected with oAuth, but with signups being free, essentially anyone can literally have all of the data my app provides.
I recently started looking into an SSR framework like Nuxt thinking this would be the solution to my problem. If I make all my RESTful calls server side, I wont have to expose my API to the world and can return HTML partials while still having the niceness of a SPA app. I know even HTML can be scraped, but I'd rather not just hand my whole database to someone in a nice JSON payload.
After playing around with Nuxt, I'm not sure this is what I'm looking for since it only does the initial REST call on the server, and all subsequent ones happen from the client. What are my options when it comes to not exposing my REST API while still having the benefits of a SPA app?
EDIT:
Some backstory if it will help: I have about 30,000 records in a database that are available through a public-facing ASP.NET MVC Core API. I limited the amount of results that can come back with a page request to 60. My VueJS/Nuxt app uses this API to display the data to the user. Since the calls happen from the client-side, my API is open to anyone who wants to hit it. That means some young, enterprising kid could write a small app that loops 500 times and will have the entirety of my database in less than a couple minutes. I know it's impossible to stop scrapers, but I'd like to make this a little harder to accomplish.
I am in the process of creating an app (cross-platform with Ionic framework) and during my research about app with this framework I found the one created for HabitRPG and it is using an API to retrieve data, it totally suits my app as well, but I don't know where to start to create an API nor what to use.
I allready did some quick test with Spring, NodeJS and Symfony (with FOS) but I'm looking for something really easy to use and to setup but still to have a lot of flexibility (like manage security, users, and data visibility).
Is there a specific technology easy enough to start with ?
If you want to create a Web API and host it, you can perhaps have the look at APISpark (http://restlet.com/products/apispark/). It's an online plateform that allows to design your APIs following REST principles and then host them. The data are also managed by the platform.
Hope it helps.
Thierry
I'm working with NodeJS + Mongoose, writing a Single Page Application, so I need to serve some statics and then all the interaction between frontend and backend is done via XHR. Eventually I'm thinking about writing a native mobile app accessing the same backend. Is there any pattern / best practice I should apply here?, I thought that I may need to extract the API to be exposed via Restify, and handle the requests from the webapp only with ExpressJS? or should I just put all the stuff exposed via Restify? I guess my confusion comes from not being worked with Restify before, so any explanation about how is it different from ExpressJS (specially when talking about a Single Page App) is really welcome.
I am implementing a similar solution, mobile app & website with expressjs and backbonejs. I did not use restify because i did not think i needed the extra complexity, there were not that many API endpoints so expressjs handled everything ok for me.
BTW take a look at this post on restify performance, I just saw it today and have not personally validate the contents.
Benchmarking APIs using PerfectAPI vs Express.js vs Restify.js « « PerfectAPI Blog PerfectAPI Blog http://bit.ly/xrTguB
Restify is packaging DTrace and various handlers that Express doesn't. If you just have one API endpoint and don't need DTrace, it doesn't make sense to run Restify.
Also, you might want to try express-resource
We have a web-based BI reporting product. We have exposed certain webservices which mainly return html content and do authentication.
We are in a initial process of developing an iPhone App, which will interact with these services and get data on iPhone.
There are couple of things we need to make sure before we start with the actual development process...
1) Should we use SOAP or REST (Will have to write the server part in Java) for the communication between iPhone and our web-application?
2) If we use SOAP, Can you suggest something, which will effectively create web services stubs in Objective-C.
3) In either case (SOAP or REST), what security mechanism is suggested by Apple?
We want to know your thoughts on the best and effective way communication could be done between iPhone app and backend servers (mostly written in Java)
Thanks in advance.
If it is an option, I'd use REST
Never did it, but may this will help: http://abhicodehelp.blogspot.com/2010/12/handling-soap-with-iphone.html
I'd do any HTTP-Communication using ASIHttpRequest. It is SSL-capable
In my apps I use simple URL requests returning XML / Cocoa-touch plists over https. I guess that's called "REST" -- it's simple and quick to implement. There are long flame-fests over SOAP vs. REST -- I just use this technique and get my apps done :)
I am working on a experimental website (which is accessible through web browser) that will act as a front-end to a restful interface (a sub-system). The website will serve as an interface between a user and the restful interface, as it will make http requests to the restful interface for almost all database operations. Authentication will probably be done using openid and authorization for the database operations will be done via oAuth.
Just out of curiousity, is this a feasible solution or I should develop two systems that accesses the database in parallel (i.e. the website has its own data access logic, and the restful interface has another data access logic)? And what are the pros/cons if I insist on doing it this way (it is just an experiment project for me to learn things like how OpenID and oAuth work in real life anyway) besides there will be more database queries and http requests generated for each transaction?
Your concept sounds quite feasible. I'd say that you'll get some fairly good wins out of this approach. For starters you'll get a large degree of code reuse since you'll be able to put other front ends on top of the RESTful service. Additionally, you'll be able to unit test this architecture with relative ease. Finally, you'll be able to give 3rd party developers access to the same API that you use (subject possibly to some restrictions) which will be a huge win when it comes to attracting customers and developers to your platform.
On the down side, depending on how you structure your back end you could run into the standard problem of granularity. Too much granularity and you'll end up making lots of connections for very little amounts of data. Too little and you'll get more data than you need in some cases. As for security, you should be able to lock down the back end so that requests can only be made under certain conditions: requests contain an authorization token, api key, etc.
Sounds good, but I'd recommend that you do this only if you plan to open up the restful API for other UI's to use, or simply to learn something cool. Support HTML XML and JSON for the interface.
Otherwise, use a great MVC framework instead (asp.net MVC, rails, cakephp). You'll end up with the same basic result but you'll be "strongerly" typed to the database.
with a modern javascript library your approach is quite straightforward.
ExtJS now has always had Ajax support, but it is now able to do this via a REST interface.
So, your ExtJS user interface components populate receive a URL. They populate themselves via a GET to the URL, and store update via POST to the URL.
This has worked really well on a project I'm currently working on. By applying RESTful principles there's an almost clinical separation between the front & backends - meaning it would be trivial undertaking to replace other. Plus, the API barely needs documenting, since it's an implementation of an existing mature standard.
Good luck,
Ian
woow! A question from 2009! And it's funny to read the answers. Many people seem to disagree with the web services approach and JS front end - which has nowadays become kind of standard, known as Single Page Applications..
I think the general approach you outline is quite feasible -- the main pro is flexibility, the main con is that it won't protect clueless users against their own ((expletive deleted)) abuses. As most users are likely to be clueless, this isn't feasible for mass consumption... but, it's fine for really leet users!-)
So to clarify, you want to have your web UI call into your web service, which in turn calls into the database?
This is exactly the path I took for a recent project and I think it was a mistake because you end up creating a lot of extra work. Here's why:
When you are coding your web service, you will create a library to wrap database calls, which is typical. No problem there.
But then when you code your web UI, you will end up creating another library to wrap calls into the REST interface... because otherwise it will get cumbersome making all the raw HTTP calls.
So you essentially created 2 data access libraries, one to wrap DB and the other to wrap the Web service calls. This basically doubles the amount of work you do, because for every operation on a resource, you will end up implementing in both libraries. This gets tiring real fast.
The simpler alternative is to create a single library that wraps access to the database, as before, then use that library from BOTH the web UI and web service.
This is assuming that your web UI and web service reside on the same network and both have direct access to the backend database server (which was the case for me). In this setup having both go directly to the database is also a lot more efficient then having the UI go through the web service.