steve-rodrigue

Please note that the goal of Rodson is to create and connect REST APIs with as few code as possible, while writing as less configuration as possible.

Let me know what you think of its syntax... the full documentation of Rodson and the full Authentication software are coming soon.

EDIT: I just wanted to share what I had so far :) Hope you like it!

Yes, that's exactly what I needed. Thanks for sharing!

Does anyone knows which app has been used to create the "handwritten" images? I draw very badly so I'm looking for such an app to explain data flows on a corporate blog/wiki.

Even if it uses views, it still binds your data storage to your RESTful API. If you use such an application, it won't be possible to move some data to other data storage, such as Redis, to normalize some data, for example, without modifying all your client's applications.

If you create an endpoint (object) based API, you will be able to modify it the way you like, and if you change your data storage, your client's applications won't even know that you modified your internal databases.

EDIT Please keep in mind that my comments are only valid if you are building an API that you will have to maintain on a long term basis. Otherwise, this project is great... like I said in another comment, I'll probably use it for simple "build and forget" projects.

Impedance mismatch happens often when directly mapping table's data to an object. When working with an API that match perfectly a database table, the user will have 2 choices (inside his client's applications):

1) Building an object from the data received from a REST call (which is the same as mapping a table's data to an object).

2) Create 1 or multiple REST calls to the API, transform the data and creates an object.

The chances that #1 happens is far greater... since #2 is normally done when building an endpoint (Object) RESTful API. So, if you would do #2, it might be a better idea to create an endpoint API and comsume it in all your client's applications...

If you do #1, your client's applications will be exposed to impedance mismatch.

Creating an API directly on top of your database schema brings the problem of impedance mismatch in all the client applications built directly on top of your new API.

However, if you create an Endpoint (Objects) based RESTful API on top of your database schema and then use this new API in all your client's applications, you will have the problem of impedance mismatch in only 1 application: your REST API.

For more information related to impedance mismatch: http://en.wikipedia.org/wiki/Object-relational_impedance_mis...

It might be a good idea to create a "build and forget" application on top of a RESTful API built directly on top of a database schema. I would probably use it for a movie website, since movie sites are normally built to promote the movie and forgotten after.

However, building client applications you need to maintain on a longer term, on top of a RESTful API built directly on top of a database schema is a terrible idea. It will get harder to maintain as the database schema evolves and the amount of client applications grows.

A good API is an API that abstract its database schema and expose designed Endpoints (Objects) to its clients.

By exposing Objects instead of your schema, your API has less chance to be updated as frequently, since its internal data storage is separated from its public API.

For the same reason, it is a bad practice to have multiple applications reading and writing data directly in your database. Building an Endpoint based API on top of your database and sharing this API across your clients is a better option.

Building an API directly on top of a database schema also brings the problem of impedance mismatch in all your client's applications: http://en.wikipedia.org/wiki/Object-relational_impedance_mis...

The problems here have nothing to do with the fact that the API might be chatty.

PHP is just a tool that makes it very easy to create quick websites using logic directly in html. I totally agree that this is a bad practice and should be avoided. This is why it attracted a lot of script kiddies at its beginning.

On the othr hand, according to Wikipedia ( http://en.wikipedia.org/wiki/Brogrammer ) a "brogrammer" is a social programmer, normally attracted in hacking jobs at startups. Therefore, I believe PHP doesn't attract "brogrammers" since most startups do not work with PHP anymore. I believe new languages attracts more "brogrammers" than PHP.

PS: Please keep in mind that, nowadays, there are a lot of good programmers that write clean PHP code. Just have a look at the Symfony2 code source.

I also believe that creating a CRUD RESTful API directly on top of your database schema is a very bad idea because of the potential impedance mismatch.

Normally, a REST API is formed of Endpoints (Objects), so this article should explain the problem fairly well: http://en.wikipedia.org/wiki/Object-relational_impedance_mis...