API usage

[joaopiopedreira]

Hi,

I'm new to Collections API. It looks awesome at first glance but I wonder if it will be applicable in my case:

• I want to expose a server API in my meteor app to allow my users to programatically perform some CRUD operations in some collections.

My question is:

• How do I give each of my users some sort of API key so that I know who's accessing the database?
• Are there any transformation functions available allowing me (for example) to transform incoming xml post requests into json before I send them to the database?

Thank you for your help.

[xcv58]

• I want to expose a server API in my meteor app to allow my users to programatically perform some CRUD operations in some collections.

It's possible, but you may need change the package manually. It depends what you want. For example, if you only need change/add/delete some fields during POST/PUT/GET, you can do it by change before functions.

But if you wanna do something more powerful like, GET only return some fields (passed from request url) of records. It requires you change the package manually.

Otherwise, you may wanna take a look of my forked version: https://github.com/xcv58/meteor-collectionapi I expose the parameter and query to application level, so you can play with them.

• How do I give each of my users some sort of API key so that I know who's accessing the database?

It's not possible, but I'm working on that. It'll be published in few days.

• Are there any transformation functions available allowing me (for example) to transform incoming xml post requests into json before I send them to the database?

You may need to use this package: https://github.com/peerlibrary/meteor-xml2js

[joaopiopedreira]

Thank you xcv58. Much appreciated.

I'm already following your fork.

[xcv58]

I have three plans to implement separate API keys for each user.

1. Implement a hierarchy auth key system inside this package. Pros:

   • we can fully control the auth system
   • can provide powerful manage policy

   Cons:

   • the package become too complex
   • require developer to import auth keys, may have issue to integrate with exist users information

2. Extend accounts-base package by add a field in Meteor.users to represent API keys. Pros:

   • the package is already there
   • less code so keep the package simple and clean
   • naturally combined with existed account system

   Cons:

   • not very flexible
   • require existed account account system
   • performance may relative low because for every request we need iterate all users. the reason is that the minimongo meteor provided can only index the _id filed.

3. expose authentication information to application level like before functions.

Developers can return true/false to indicate whether the auth key is valid. The developer should provide a callback function like:

  AUTHENTICATE: function(key, method, requestMetadata) { 
    // key is the auth key request provide
    // method is the request method, should be one of 'POST', 'GET', 'PUT', or 'DELETE'
    // requestMetadata contains metadata for the request, list below.
    return true/false;
  }

Request like this should have requestMetadata below:

curl http://localhost:3000/collectionapi/players/id/field/subfield?query1=1&query2=2 -d '{"a" : 1}'

 requestMetadata = {
    collectionPath: 'players,
    collectionId: 'id',
    fields: [ 'field', 'subfield' ],
    query: {
      query1: '1',
      query2: '2'
    }
  }

Pros:

• the most flexible way to provide multiple auth keys
• the simplest way to keep this package clean and simple

Cons:

• need developers do more work to let this work, but it depends on how complex develop want. He/she can just return true; for every request, or just provide different keys for different request methods. All depends on developers.

---

Could you please tell me which way you prefer and why?

I personally prefer the third ways.

[joaopiopedreira]

Hi Xcv58,

I like very much the third option. It's very flexible and it works like a natural extension of the existing API.

Cheers,

On 11 March 2015 at 16:40, xcv58 [email protected] wrote:

I have three plans to implement separate API keys for each user.

Implement a hierarchy auth key system inside this package. Pros: - we can fully control the auth system - can provide powerful manage policy

Cons: - the package become too complex - require developer to import auth keys, may have issue to integrate with exist users information 2.

Extend accounts-base package by add a field in Meteor.users to represent API keys. Pros: - the package is already there - less code so keep the package simple and clean - naturally combined with existed account system

Cons: - not very flexible - require existed account account system - performance may relative low because for every request we need iterate all users. the reason is that the minimongo meteor provided can only index the _id filed. 3.

expose authentication information to application level like before functions.

Developers can return true/false to indicate whether the auth key is valid. The developer should provide a callback function like:

AUTHENTICATE: function(key, method, requestMetadata) { // key is the auth key request provide // method is the request method, should be one of 'POST', 'GET', 'PUT', or 'DELETE' // requestMetadata contains metadata for the request, list below. return true/false; }

Request like this should have requestMetadata below:

curl http://localhost:3000/collectionapi/players/id/field/subfield?query1=1&query2=2 -d '{"a" : 1}'

requestMetadata = { collectionPath: 'players, collectionId: 'id', fields: [ 'field', 'subfield' ], query: { query1: '1', query2: '2' } }

Pros:

• the most flexible way to provide multiple auth keys
• the simplest way to keep this package clean and simple

Cons:

• need developers do more work to let this work, but it depends on how complex develop want. He/she can just return true; for every request, or just provide different keys for different request methods. All depends on developers.

---

Could you please tell me which way you prefer and why?

I personally prefer the third ways.

— Reply to this email directly or view it on GitHub https://github.com/crazytoad/meteor-collectionapi/issues/43#issuecomment-78301981 .

[xcv58]

Cool, I'll do that. I'll tell you when it's ready.

[joaopiopedreira]

Thanks :-)

On 12 March 2015 at 00:02, xcv58 [email protected] wrote:

Cool, I'll do that. I'll tell you when it's ready.

— Reply to this email directly or view it on GitHub https://github.com/crazytoad/meteor-collectionapi/issues/43#issuecomment-78399497 .

[xcv58]

I did that, https://github.com/xcv58/meteor-collectionapi/releases/tag/v0.2.0

Please tell me if you find any bug!