It looks like these are aliased, is there a compelling reason for removing them all as opposed to fixing the plugin?

I'm 👍 on consistency, and it seems like all of these are actually synchronous so we could just create a getter on the property (i.e. length = res.contentLength). While making the setter no-op and creating a getter may make this API a bit more clean, I'm worried about migration costs for making this change. It seems like this will break user-land in a massive way.

@retrohacker - I would suggest that the query parser behaviour of setting res.query to a hash object is the expected behaviour rather than the aliased behaviour of duplicating res.getQuery().

For me aliases are a fine for keeping backward compatibility for semvar minor release but should be removed when doing a semvar major release. The Restify v5 release contains a number of API changes so I don't see the problem in doing a bit of code maintenance.

Met the same question, I am using node6.9.4, express 4.3.0 and restify 5.0.0, restify will make request.query to be a function, so that express can't parse the query string any more, because it's not null(express.middleware.query.js 39). And it broke down my project. Restify 4.3.0 works fine.
BTW, actually I don't need to use restify, but I need bpmn, and bpmn will require restify, so......,

Marking this as ready to implement, as it would be nice to have compatibility with express. @yunong and @DonutEspresso, chime in if you disagree.

I suspect many of the aliases are from before they existed in node core. Agree - it makes sense to use the now native methods where possible.

Related: #1422

Related: #1529

Hello,

I am starting to work on this and i understand the problem. I will explain what i understand of the problem and you can correct me if i am wrong.

1. Methods such as req.path() are aliased to getPath() function in request.

2. I could not find the same alias or function in response module and all the above examples are given for response which is strange. Please let me know if i am missing something.

3. We need to get to native like functionality so that getPath() is the default behaviour rather than Path()

4. Does this mean that we remove req.Path() completely? Can we have path as a property with a value of getPath()?

5. Now after this change req.Path() will stop working, wouldn't this break the system already using .Path() function?

6. I found 6 properties like that which have corresponding get property in request module and NONE in response module.

contentLength
contentType
href
path
query
version

Please confirm my thoughts. I apologise in advance if I sound ignorant at some places as this is my first stab in open source world and i am not a Rockstar in javascript as well.

Thank You
Logeekal