Show HN: Rest – Instant RESTful API on Any SQL Database(github.com)
github.com
Show HN: Rest – Instant RESTful API on Any SQL Database
https://github.com/rest-go/rest
11 comments
The original idea was inspired by PostgREST, the obvious difference is Rest tries to support all SQL databases, and it results in some design principle that Rest prefers to use a universal method instead of bind to PG features(e.g. use PG role for user authorization). Generally PostgREST is more mature now if you are using PG.
Thanks for liking it, I also think it could be a good tool to help developers for rapid prototyping and development.
Nice, does it support JSON/JSONB fields for psql?
Edit after RTFM: it apparently does. https://rest-go.com/docs/guides/api#query-json-columns
Edit after RTFM: it apparently does. https://rest-go.com/docs/guides/api#query-json-columns
Fully RESTful, yet no mention of hypermedia.
No mention of HATEOAS, hypertext, not even bare minimum "RESTful hyperlinks".
Thanks for mention it, it should be a feature for this kind of tool, put it on my plan.
It would be great if it could support NoSQL databases as well. I use DynamoDb as an example, and I had to write REST APIs myself.
Yes it would be great. But this is kind of like saying people who have a pattern for making quilts should use their techniques to get into the sheet business. On the surface it makes sense, but when you dig into the details it turns out that the way you make quilts and the way you make sheets are so fundamentally different it’s not even worth exploring a common ground. Yes we both make things that go on peoples beds, but the manufacturing internals are so completely different that it’s not even worth having the conversation about how they could be married.
While yes, this makes a ton of sense, I'm voting this up specifically for using a quilting metaphor to explain geekery. ;)
Curious about the name. Why just "Rest"?
I didn't spend much time on naming, the original idea was inspired by an interesting project PostgREST which is a similar tool bind to Postgres, so I just name it as Rest which could provide RESTFul API for any SQL database.
Generally been a fan of these sorts of models - SQL data is very malleable - and treating the tables as movable from the start really helps move faster as a developer - database migrations become easier as you don't need to do a lot of work with API.
I can see how this would cause problems if you always used this in production after finding a fit for the data model - but for rapid prototyping and development - big fan.