Restify: Fix for calling next()

[jadkap]

Follow up to #189

• Added next() calls and type annotation for restify.Next. In order for restify’s "after" event to fire (like triggering a call to auditLogger), next() needs to be called after sending a response. From http://restify.com/#routing: "Note the use of next(). You are responsible for calling next() in order to run the next handler in the chain."

• I also discovered something with Restify’s bodyParser that results in an inconsistent response in a particular scenario vs. Koa and Express (didn’t check Hapi). Restify’s bodyParser returns undefined (vs. Express & Koa returning {}) if body parser is used but no request body is sent. This test https://github.com/apollostack/graphql-server/blob/master/packages/graphql-server-integration-testsuite/src/index.ts#L212-L221) passes because it’s not specifying any body parser, so all server variants return undefined. What’s happening is that in the case of Restify, if you use bodyParser, but don't send body, GraphQL is responding with 500 ‘POST body missing. Did you forget use body-parser middleware?’ whereas the same scenario in Koa and Express variants return 400 "Cannot read property 'definitions' of undefined" in nested error response. I started fixing it in the graphql restify code, but then that breaks the above test for Restify. Workaround is to either add validation middleware before calling graphqlRestify() or add a server.pre() handler to convert the body to {} if it’s undefined and content-type is application/json.

[apollo-cla]

@jadkap: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[joelgriffith]

Good catch on the omission of the post body... I'll have to stew on that one.

The next stuff looks good, probably good to merge

[DxCx]

Thanks!