Hacker News Reader

Comment by sergiotapia | Hacker News Reader

Wow, I'm building something a bit similar in the Go area: https://github.com/sergiotapia/paprika

Nice to know it's a good idea that a lot of people will find useful. :) Granted in it's current vision Paprika won't handle authentication.

It's basically an API server in-a-can. Defined your structs, set up your .toml database configuration and paprika.Start("3000") on a port.

View on HN

I've seen ton of "expose DB as REST-like API" libraries in various languages, and even tried (unsuccessfully) to write one myself. I'd say just exposing model is trivial, even when coupled with content-type negotiation. Subjectively, the hardest part is permissions (operation, row and field-level ones) and making them play nice with REST and HTTP concepts (like ETags).

etags , hateoas,hypermedia... definetly the hard part,along with security. Getting an API right is hard work.Still search for the holy grail...

Agree. We try to solve the problems progressively. The connected model support is a foundation to those features. See http://strongloop.com/strongblog/defining-and-mapping-data-r.... Basically, we build models that relate to each other, partition the data graph with links, and expose them as REST APIs that can be used to navigate and aggregate the information from various data sources.

I've found that with a stack based around middleware (Express) , that it's now very easy to add open source modules to handle these features for you.

What interests me a lot at the moment are HTTP proxies that provide features like these. I like the encapsulation and scalability that true REST makes easy.

I would say writing the "expose DB as REST-API" can be easy for small projects, but a lot of work can go into making something that is RESTful, scalable, and a joy to build with.

Reply on news.ycombinator.com