
Ask HN: Simplest way to build a REST API? - ryanmccullagh
I&#x27;m currently planning for a mobile application implementation that will use a REST API as a backend proxy to a MySQL database -- This seems like the most logical way to do it, as I&#x27;m not going to expose MySQL to the world.<p>What frameworks are there that can support rapid development -- I need a router, and some type of database abstraction library with prepared statements of course.<p>I don&#x27;t want to get tied into vendor lock in with other services that provide an API platform as service, and I don&#x27;t want to use the AWS database as a service, because again, I don&#x27;t want to get tied into vendor lock in, so I&#x27;d rather keep this thing as portable as possible.
======
abowen
DreamFactory automatically generates REST APIs for you...may want to check it
out! You can build your mobile, web or IoT apps using their platform and
connect to nearly any database. :)

p.s. it works great with MySQL and supports great authentication, security and
user role layers and mgmt features. DreamFactory also has a free, open source
version. reply

------
dozzie
Why not going simply with a proper RPC protocol? You're going to do it this
way anyway, except you'll strangle yourself with a mess of URLs and request
routers and ORMs and whatnot, but without well-defined protocol with sane and
consistent error reporting.

~~~
ryanmccullagh
I am leaning towards using HTTP. RPC doesn't seem like it would be a good idea
in 2016. I would then have to expose a RPC service to the world. I don't have
any background in deploying an RPC service, but I do know how to deploy and
secure a HTTP service to the world. Is RPC really used anymore?

~~~
dozzie
> I am leaning towards using HTTP. RPC doesn't seem like it would be a good
> idea in 2016.

Quite the contrary. RPC is an _excellent_ idea in 2016, if you're willing to
forego "trendiness". It gives you pretty much the same as you're getting from
what people today call "REST API", but already has defined how to report call
results and errors and doesn't require you to juggle with API endpoint URLs,
so it's a win in pretty much every field.

> I would then have to expose a RPC service to the world.

Yet you don't seem concerned with exposing the same thing with the same
operations with HTTP.

> I don't have any background in deploying an RPC service, but I do know how
> to deploy and secure a HTTP service to the world.

Use some HTTP-based RPC protocol, then. Little difference, really.

------
perfmode
Try Ruby on Rails with Amazon RDS. Simple. Battle-tested. No lock-in.

