The proposed scheme has issues in several areas.
URL paths are frequently logged; putting unhashed passwords in the path is poor practice.
Authentication/authorization information should appear in the Authorization header. Or potentially, for browser-based stuff, the Cookie header.
Verbs such as
resetpassword in your URL are generally a clear sign of a non-representational state transfer paradigm. A URL should represent a resource. What does it mean to GET
resetpassword? Or DELETE?
This scheme requires always knowing the previous password. You will probably want to allow for more cases; e.g. the password is lost.
You could use Basic or Digest authentication, which is are well understood schemes.
PUT /user/joe/password HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
It doesn't put ultra-sensitive information in the path, and it follows HTTP and REST conventions.
If you needed to allow for some other mode of authorization (e.g. some token sent through a verified channel to reset the password), you can simply use a different Authorization header without having to change anything else.