Question

I’m exposing a more or less public API that allows the user to query datasets from a database. Since the user will need to filter out specific datasets I’m tempted to accept the WHERE-part of the SELECT statement as an API parameter. Thus the user could perform queries as complex as she’d like without worrying about a cluttered API interface.

I’m aware of the fact that I would have to catch SQL-injection attempts.

Do you think that this would circumvent the purpose of an API wrapping a database too much or would you consider this a sane approach?

Answer 1

In general, I’d recommend against letting them embed actual sql in their requests

You can allow them to submit where conditions in their request pretty easily:

<where>
    <condition "field"="name" "operator"="equal" "value"="Fred"/>
</where>

or something similar.

The value of doing this is muli-fold:

1. You parse each condition and make sure they’re correct before running them
2. You can create ‘fake’ fields, such as “full_name” that may not exist.
3. You can limit the columns they can put conditions on
4. You can isolate the users from actual changes in your underlying database.

I think the last point is actually most important. The day will come when you’ll need to make changes to the underlying schema of the database. Eventually, it will happen. At that point you’ll appreciate having some ‘translation’ layer between what the users send in and the queries. It will allow you to isolate the users from actual changes in the underlying database.

The API should present an ‘abstracted’ version of the actual tables themselves that meet the users needs and isolate them from changes to the actual underlying database.