Compatibility with mdg:validated-method and roadmap

[tcastelli]

Hello, this package looks nice and a really easy way to get a quick REST API. Still, I was looking for a few things before jumping in (comparing this with restvivus atm) so I would like to know the current positioning regarding:

• Compatibility with mdg:validated-method
• Compatibility/Integration with restivus
  • In case the previous one is discarted
  • Api versioning possibilities (like some methods are on v1, others hidden, v2/private)
  • Custom auth (based on current login with bearer token but with additional checks)
  • Possibility to define new methods for API use only

[stubailo]

validated method should work out of the box, since this literally just overrides Meteor's method registration mechanism.

I don't have a lot of time right now to look at integration with restivus. What kind of integration were you thinking? I can't see any reason you wouldn't just use both in the same app.

As for defining methods for API use only, I'm not sure why you would do that - thoughts?

[tcastelli]

Thanks for the quick reply, and yes, quite hard to find time around holidays, so no hurries :)

If I get this correctly you mean that we can do for example

const methodBody = function(){} //...
const restOptions ={}; //url,...

const method = new ValidatedMethod({
  name:"return-five", 
  validate:null,
  run: methodBody 
});
 and then

Meteor.method("return-five", methodBody , restOptions );

Is it possible to add this directly into validated-method(something like this)?

const method = new ValidatedMethod({
  name:"return-five", 
  validate:null,
  run: methodBody 
  rest:restOptions
});

As for the integration with restivus, I have been checking again and I have thought of how to do previously commented things without adding both packages (In my opinion having both packages for doing basically the same thing makes no sense and just adds an extra effort to follow the updates of both projects).

Correct me if I'm wrong but:

• API versioning -> Should be controled from simple-rest url parameter, adding /v1 or v2 when needed (this doesn't allow using the same endpoint for both versions but well...),

  would be nice if the url key was an array of string instead so we could define multiple endpoints to call the same method.

• Custom auth -> Here is where restivus offers more flexibility. Don't get me wrong, I really like simple:rest-accounts-password approach, which is more standard in terms of use (everyone is using Bearer Token), but I don't want every account to be able to use the API, so I guess I'll just have to fork rest-accounts-password and make my own checking before returning the userid

  would be nice if the login function could be extended with and additional check for the user(a function ideally) besides having correct user/password.

• DDP or API only calls-> the first use case that comes to my mind is webhook endpoints, which are normally not exposed to the standard application and should be more or less hidden to avoid "evil" calls. Also for example I may not be interested in oferring a "DDP" method over the REST API, let's say register users(which uses a custom method). I know I could remove it from JSONroutes but integrating this kind of functionality from this package would make things much easier.

  would be really helpful to decide if the method is visible through HTTPS, DDP or both.

[tcastelli]

@stubailo any thoughts about adding this to the validatedmethod package and the other 3 topics? I later saw that the API versioning topic was already debated but not sure what was taken as a result of that discussion(I guess that If we want that we have to use retivus for now), but also would like to know your opinion about custom-auth and DDP/HTTP only

[aldeed]

@tcastelli Some thoughts I have:

1. I'm generally with @stubailo that everything should be available through both, even if you don't intend for it to be used that way or don't document it. In the end it's just a matter of which protocol is used, so your app logic shouldn't care. BUT, this does not seem like something the package should be opinionated about, so I think the easiest solution is to add this.isDDP and this.isHTTP booleans that you can check in the method, like if (this.isHTTP) return; The endpoints would still be created, but would be no-op if you want.

2. You can use your own middleware to reject requests from certain users. Add simple:rest-accounts-password and simple:rest-json-error-handler unmodified. Then

   JsonRoutes.Middleware.use(function (req, res, next) {
    if (!checkUser(req.userId)) throw new Meteor.Error('unauthorized', 'Sorry, you cannot access this');
   });

3. I think it would be great if core methods eventually had extendable options that various packages could use to enable validation, rest, and other icing. Maybe validated-method could try out an API for that and then pull into core after fine tuning if it makes sense.

[stubailo]

I'm testing out something like this:

ValidatedMethod mixins: https://github.com/meteor/validated-method#mixins

simple:rest mixin: https://github.com/stubailo/meteor-rest/blob/master/packages/rest-method-mixin/README.md

[tcastelli]

@aldeed 1) this.isDDP and this.isHTTP would be fine for me, but in the end, if we already have those, making general abstraction to return no-op for the methods that you want should be trivial (so maybe it could be enabled by default in validated-method or a mixin before exceuting the run function). what do you thinkg about something like this

ValidatedMethod.http_methods = ["login","logout"]; //by default all of them
ValidatedMethod.ddp_methods = ["register"]; //by default all of them

const method = new ValidatedMethod({
  name:"login", 
  validate:null,
  run: methodBody
  restOptions: {...}
});

and then in validated-method before executing the run function add something like

if (this.isHTTP && _.contains(ValidatedMethod.http_methods,this.name) || this.isDDP &&  _.contains(ValidatedMethod.ddp_methods,this.name) )
   return this.run()
else exception or ignore
} 

2) Will dig into that and try it out, thanks for the idea 3) Mixins seem a great addition to introduce customization in validated-method so will try that soon too thanks @stubailo :)