2

I am designing an api that can give developers read-only access to a large dataset. The data is stored in a mongodb database.

All the results of the api, will basically either be a count of matches to a certain query filter, or returning the actual rows that match the query filter.

If possible, I don't want to limit how developers can search in this dataset because they will no doubt come up with relationships / uses in the data that I haven't thought of.

It seems to me that this could be achieved by using mongodb's own query object syntax as one of the query parameters, e.g. a JSON object like follows:

{ team: { $eq: 'Crystal Palace' }, goals: { $gte: 2 } }

which specifies that the matches in which Crystal Palace scored 2 goals or more.

So the api user would make a POST request, which has a JSON object as the body, part of which is the above query object which I can validate and then use directly in a query:

Pros

  • The users of the data can make any query they want. I think if I used get requests, then expressing complex queries would get pretty complicated.
  • I think for this particular case, I can reduce the development time for all of the possible api calls, because there is really only 1 route. I just need to implement validation on the query object. I still have control of whether to execute the query or not and the fields which the api will return.

Cons

  • I wonder if there are any security concerns? As mentioned above the user will not be able to specify the fields which are returned and will only be able to query the 1 collection on a read-only basis so I don't think that there will be an issue.
  • I think most developers will be used to multiple get routes with different uri params so using this method does force the users to learn mongodb syntax. Then again, not only do I intend to document the api very well, but the developer could also fall back on the mongodb docs if they get stuck.
  • what is the addon value of having your own api? if developers have to learn mongo-style queries why not using mongodb directly? – k3b Oct 21 '15 at 11:15
  • @k3b Yes. That's what I have proposed to do above. Unless I have misunderstood your question. I don't want to just give developers direct access to the database and I couldn't allow them to just execute mongo db statements directly because they could execute any javascript. It is just the query parameter of the find() method which filters down their search results which I propose to have in the mongodb syntax. – Joe Oct 21 '15 at 11:48
  • 3
    @Joe Some points you might consider: Will you ever want to change databases? What if a version of MongoDB changes its query syntax and your users want to use that -- will your validation logic cope? Do you want your users to have to consult two documentation sources (one external!) to use your API? – paul Oct 21 '15 at 12:30
  • @paul Yep. Good points. I intend to make my documentation very good, so hopefully they won't need to use mongodb's. Having to cope with mongodb's own api changes is not something I've considered, so I'll have to think about that one. – Joe Oct 21 '15 at 13:14
  • I guess another thing that I hadn't considered is how optimised the query would be. It's a large db and I guess it would be possible for users to come up with some pretty slow queries. – Joe Oct 21 '15 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.