Is a restful API and a backend service (like Parse) the same thing?

Question

Rest confuses me sometimes. I know that it involves creating an API layer over your data and then you make calls to that data through the API. The best way I think of Rest is that the actual Twitter website interfaces with the data-layer through API calls.

That made me wonder then: Is a backend-service like Parse also a Rest API to your data?

What might be the difference between Parse and say, building your own Rest API like this guy did: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ (he's getting some solid google rankings for his API tutorials).

A simple yes/no might answer the question, but providing details will really be appreciated.

I look forward to the answers.

Answer 1

Parse is built around a restful API just like most, if not all, other mBaaS out there. A RESTful Api isn't just CRUD operations though nor is it the same thing as Parse. Parse is a company that provides a remote backend to developers using a RESTful api.

RESTful api !== BaaS

I have dealt with about 5 mBaaS and Parse isn't really one of them, but I've glanced at their API reference for JS and I think they use mongodb clusters. An mBaaS usually provides the developer the ability to have cloud storage, push notifications, server side code, easier social media integration, and mobile analytics. So it's not just any backend. Although there are some mBaaS, like Urban Airship, that only supply push notifications to developers.

A RESTful api at it's core usually has some key functions that are centered/wrapped around an httpRequest

They usually use "GET", "POST", "DELETE", and "PUT" to make all calls. Some allow the implementation of rpc for custom server logic. An mBaaS takes a lot of work to implement right and well. You can't build Parse in a Day. It takes a lot of planning and such. The differences between Parse and that guy in link are in the implementation, range of features, and purpose in general(the audience).

To better understand REST maybe look here you can also read the HTTP spec if you are feeling adventurous.