Existing similar things: (from worst to best)
Not looking good. Seems to charge a lot of money and not open.
Looks very crappy and not active. All XML
Looks a little less crappy. Does have a github https://github.com/restsql/restsql . And looks does have some activity.
Very barebone. Things are configured with XML. But it’s Java and can be extended. The docs and stuff makes sense. Can be used as a Java Library, but if used like that, why not use a proper ORM like Hibernate?
Looks easy to use. Written in python and heavily influenced by Django clearly. Not active for a year, but the automatically inspect db using reflection is a good idea.
Django Tastypie and Django REST framework. These two looks good but then you have to buy in Python Django. And still a lot of things to setup and code to write.
Looks good and professional. Concern about how open it is. It says Apache 2.0 Licence though, so maybe good. Very active https://github.com/dreamfactorysoftware/dsp-core Written in PHP. Seems to have much broader range, stuff like client side library etc. Support SQL, NOSQL, etc and more importantly, seems at the same time. Even have a Docker image ready.
Seems to be the best choice so far.
- REST to SQL CRUD operations.
- REST to SQL LFSP (I invented this List Filter Sort Pagination) operations
- Cross table joins. Nested return. This maybe optional in an AJAX world. But may be necessary for complicated logics. However, when you consider if this supports multiple data sources, you cannot avoid in memory join, so maybe an in memory join support is more useful. Maybe you need to query one data source and then query another based on previous result. IN clause maybe a problem here since MySQL is not very good at it and Oracle even have a 1000 limit.
- API version controls that supports multiple versions.
- Maybe you simply need multiple sets of things completely (including different databases for different versions. Let’s face it, different versions probably require different db schema) and you have another service layer on top and when a request comes in, you call call one version easily but if it is a write request, you need to convert the request to make sense for other versions and make additional requests. Still this poses a big problem for data out of sync.
- Maybe you have multiple tables for different versions but the transaction will update all of them. Less problematic because it is in a transaction?
- Automatically generate documentations.
- An admin UI for modifying the data
- CLI for the following admin stuff:
- Configure database connection results in configuration file. Commit to git? Maybe only the connection and configuration but not the credentials.
- Create new edit existing table/resource results in schema migration and data migration files. Commit to git? Or should this be in database? Or should the schema migration be in git and data migration in database.
- Automatically have createdAt and updatedAt ?
- Optionally have complete history on some table? I don’t mean SQL history. That is in a big SQL log already. But history with who modified what. Very useful for audit. How does this work when schema changes?
- Use existing db through reflection. But this may not be necessary. Or this could be the killer feature.
- Maybe a JSON REST API and admin UI for these admin work above. But keep in mind that when there is an API and UI, how can we commit to git for the changes? Maybe should learn from the versioned wordpress.
- ACL Access Control Level. This may exists in a completely different layer on top of what we have above. We are not going to create a mysql user for each user of the system to leverage database’s access control, that will create a lot of connections to the database. So although ACL data is saved in database but it has to be the service that make sense of it and grant or deny access.
- Customize business logic.
- Support NOSQL and other types of datasource.
- Support multiple and multiple types of datasource together. I definitely feels better if this is another layer on top.