13 Nov 2019 - by 'Maurits van der Schee'
In my career I have seen many REST APIs. They all implement Create Read Update and Delete (CRUD) on single entities with verbs as described by the REST standard. All of them do the same 4 (additional) things: column filtering, row filtering, authorization and document nesting. In this post we will look at a few implementations and explore a system for maturity qualification of a REST API implementation.
As a software architect I'm interested in standards and standard implementations. We will evaluate a few implementations and score the 4 additional tasks on the following scale:
Lets get started!
In the table below you can read the maturity level of various implementations:
|API||Column filtering||Row filtering||Authorization||Document nesting||Score|
|PathQL-Flask/Go||SELECT / DB||WHERE / DB||GRANT / DB||PathQL / -||9|
|PostGraphile||GraphQL / -||GraphQL / -||GRANT / PG||GraphQL / -||9|
|Hasura||GraphQL / -||GraphQL / -||- / -||GraphQL / -||6|
|PostgREST||- / -||- / -||GRANT / PG||- / -||3|
|PHP-CRUD-API||TreeQL / -||TreeQL / -||- / -||TreeQL / -||0|
As you can see the score of TreeQL and PathQL are on the bottom and on the top, pursuing different architectural goals. PHP-CRUD-API tries to be a generic full-featured REST implementation, mainly due to the lack of a powerful REST standard. PathQL-Flask tries to implement as little as possible, using database (and other) standards where available.
If you don't know any of the above I would recommend to give PostGraphile a try as it lets you build an endpoint for the super popular GraphQL protocol with almost no effort.
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.