Routes - pcimino/nodejs-restify-mongodb GitHub Wiki

Routes in routes.js

The route definition files determine how the server should respond to incoming requests.

Pre

The pre() function intercepts the incoming request. In this case I modify / or /public to reference the index.html file. For a pure REST API there isn't much use for a static server. Static ccontent could be served up from another resource. However for this project I want the ability to demonstrate, if not fully test, the APIs.

Serving Static Content

All GET requests with /public/ in the URI open the resource and write it to the response. This works for HTML or binary content.

Open Access

/api

  • Get
  • Input: None
  • Response: {'message':'Success'} if connected

/db

  • Get
  • Input: None
  • Response: 200 if db connected

/api/v1/user

  • Post
  • Input: user fields: name, username, email, password, vPassword (verify)
  • Response: user object, sends email with verification code

/api/v1/user/username/exists

  • Get
  • Input: username
  • Response: 200

/api/v1/user/email/exists

  • Get
  • Input: email or newEmail
  • Response: 200

/api/v1/verify/resend

  • Get
  • Input: username (if config.usernameOrPassword is true, then either email or username can be used as input)
  • Response: 200, emails a new verification code

/api/v1/password/sendNew

  • Get
  • Input: username (if config.usernameOrPassword is true, then either email or username can be used as input)
  • Response: 200, generates and emails a new password

Authenticated User

/api/v1/email

  • Post
  • Input: to, subject, message
  • Response: 200, sends email

/api/v1/userlist

  • Note: Need a new API, or filter based on Role access. Admin can see ull user list. For Users seeking other Users, need a subset object, maybe just username, maybe email, depending on application context.
  • Get
  • Input: UserList object. Default search values: pageNum (0), itemsPerPage (10^12-1), ascendingSortFlag (true), name (''), email (''), username ('*'), sortField ('')
  • Response: 200, populated UserList object

/api/v1/user

  • Get
  • Input: {none}
  • Response: authenticated user's own information

/api/v1/user/:search

  • Get
  • Input: add the username or the Object Id to the path: /api/v1/user/myusername
  • Response: requested user's information
  • Restrictions: For Admin role only

/api/v1/user

  • Put
  • Input: User populated with information. If password, vPassword (verify) and cPassword (Current) are accepted. If email is successfully updated, verification code gets emailed
  • Response: User object

/api/v1/admin/user

  • Put
  • Input: Same as /api/v1/usr, allows Admin to other user's data including Role can be set to Admin
  • Response: User object

/api/auth

  • Get
  • Input: checks to see if valid session is active
  • Response: {'message':'Success'}

/api/v1/session/login

  • Post
  • Input: username, password (if config.usernameOrPassword is true, then either email or username can be used as input)
  • Response: Validated session cookie

/api/v1/session/logout

  • Get
  • Input: valid session
  • Response: invalidates session

/api/v1/messageThread

  • Post
  • Input: valid session, subject, message, toUsername, toUserId
  • Response: messageThread
  • Put
  • Input: valid session, messageThreadId, message
  • Response: messageThread
  • Get
  • Input: valid session, archiveFlag, senderFlag (true retrieves messageThreads user started, false: messageThreads started by another user)
  • Response: retrieves array of non-archived messageThreads by default, if archiveFlag true, retrieves archived threads
  • Delete
  • Input: valid session, messageThreadId
  • Response: archives the message

/api/v1/roles

  • Get
  • Input:
  • Response: Returns a valid list of roles: ['User', 'Subscriber','Admin']

I set up 3 roles, but it's pretty easy to see how you would modify this.

  • No defined role: Users default to user role, so shouldn't happen.
  • User : Accessible by Users with User, Subscriber and Admin roles
  • Subscriber : Accessible by Users with Subscriber and Admin roles
  • Admin : Accessible by Users with Admin role

/api/v1/verify

  • Get
  • Input: v with the generated verification code
  • Response: success if the email address is validated, updates the user in the db

/api/v1/roles/access

  • Note: This is for debugging/testing, for locking APIs down the APIs should use the middleware methods adminAccess and subscriberAccess
  • Get
  • Input: role
  • Response: {'message':'Success'} if the user's access is >= queried role

Currently Roles are heirarchy based: Admin can see everything. Conceivably APIs could requie explicit roles (Subscriber OR Admin) seperating behavior instead of making the admin an uber user.

Administrator

/api/v1/user

  • Delete
  • Input: User ObjectId
  • Response

Next: Session Management

Return Home