phhorton/classroom-project-javaoracle

Banking API

The Banking API will manage the bank accounts of its users. It will be managed by the Bank's employees and admins. Employees and Admins count as Standard users with additional abilities.

• Employees can view all customer information, but not modify in any way.
• Admins can both view all user information, as well as directly modify it.
• Standard users should be able to register and login to see their account information.They can have either Checking or Savings accounts.
• All users must be able to update their personal information, such as username, password, first and last names, as well as email.
• Accounts owned by users must support withdrawal, deposit, and transfer.
• Transfer of funds should be allowed between accounts owned by the same user, as well as between accounts owned by different users.

Models

The below models are an outline that supports the required features. They can be expanded or modified as needed.

User

The User model keeps track of users information.

public class User {
  private int userId; // primary key
  private String username; // not null, unique
  private String password; // not null
  private String firstName; // not null
  private String lastName; // not null
  private String email; // not null
  private Role role;
}

You may optionally consider to include a List<Account> field in the User model. Some tasks will be easier, and others harder. In particular, this complicates every request that would need an entire User object, such as Register and Update User, since they would need to include the accounts as well. It would be up to you to resolve this.

Role

The Role model keeps track of user permissions. Can be expanded for more features later. Could be Admin, Employee, Standard, or Premium

public class Role {
  private int roleId; // primary key
  private String role; // not null, unique
}

Account

The Account model is used to represent a single account for a user

public class Account {
  private int accountId; // primary key
  private double balance;  // not null
  private AccountStatus status;
  private AccountType type;
}

AccountStatus

The AccountStatus model is used to track the status of accounts. Status possibilities are Pending, Open, or Closed, or Denied

public class AccountStatus {
  private int statusId; // primary key
  private String status; // not null, unique
}

AccountType

The AccountType model is used to track what kind of account is being created. Type possibilities are Checking or Savings

public class AccountType {
  private int typeId; // primary key
  private String type; // not null, unique
}

Endpoints

The below endpoints generally follow a RESTful pattern. Where the URI describes the relevant resource and the HTTP Method describes the action to perform. Path variables (e.g. /:userId) are used to identify specific resources as part of the URI. These are placeholders, such as for a userId. If not otherwise specified, the response status code should be 200 OK.

Security

Security should be handled through session storage. If a user does not have permission to access a particular endpoint it should return the following:

• Status Code: 401 UNAUTHORIZED Content:

  {
    "message": "The requested action is not permitted"
  }

  Occurs if they do not have the appropriate permissions.

RPC Endpoints

These endpoints are not RESTful, but are included to more conveniently simulate user actions

Login

• URL: /login

• Method: POST

• Request:

  {
    "username": String,
    "password": String
  }

• Response:

  User

• Error Response:

  • Status Code: 400 BAD REQUEST

  {
    "message": "Invalid Credentials"
  }

Logout

• URL: /logout

• Method: POST

• Response:

  {
    "message": "You have successfully logged out {username}"
  }

• Error Response:

  • Status Code: 400 BAD REQUEST

  {
    "message": "There was no user logged into the session"
  }

Register

• URL: /register

• Method: POST

• Allowed Roles: Admin

• Request: Note: All fields must be included and the userId should be zero

  User

• Response: Note: The userId should be updated

  • Status Code: 201 CREATED

  User

• Error Response: Note: In case username or email is already used

  • Status Code: 400 BAD REQUEST

  {
    "message": "Invalid fields"
  }

Withdraw

• URL: /accounts/withdraw

• Method: POST

• Allowed Roles: Admin or if the account belongs to the current user

• Request:

  {
    "accountId": int,
    "amount": double
  }

• Response:

  {
    "message": "${amount} has been withdrawn from Account #{accountId}"
  }

Deposit

• URL: /accounts/deposit

• Method: POST

• Allowed Roles: Admin or if the account belongs to the current user

• Request:

  {
    "accountId": int,
    "amount": double
  }

• Response:

  {
    "message": "${amount} has been deposited to Account #{accountId}"
  }

Transfer

• URL: /accounts/transfer

• Method: POST

• Allowed Roles: Admin or if the source account belongs to the current user

• Request:

  {
    "sourceAccountId": int,
    "targetAccountId": int,
    "amount": double
  }

• Response:

  {
    "message": "${amount} has been transferred from Account #{sourceAccountId} to Account #{targetAccountId}"
  }

RESTful Endpoints

These endpoints are RESTful, and generally provide basic CRUD operations for Employees/Admins

Find Users

• URL: /users

• Method: GET

• Allowed Roles: Employee or Admin

• Response:

  [
    User
  ]

Find Users By Id

• URL: /users/:id

• Method: GET

• Allowed Roles: Employee or Admin or if the id provided matches the id of the current user

• Response:

  User

Update User

• URL: /users

• Method: PUT

• Allowed Roles: Admin or if the id provided matches the id of the current user

• Request: Note: All fields must be included

  User

• Response:

  User

Find Accounts

• URL: /accounts

• Method: GET

• Allowed Roles: Employee or Admin

• Response:

  [
    Account
  ]

Find Accounts By Id

• URL: /accounts/:id

• Method: GET

• Allowed Roles: Employee or Admin or if the account belongs to the current user

• Response:

  Account

Find Accounts By Status

• URL: /accounts/status/:statusId

• Method: GET

• Allowed Roles: Employee or Admin

• Response:

  [
    Account
  ]

Find Accounts By User

• URL: /accounts/owner/:userId For a challenge you could do this instead: /accounts/owner/:userId?accountType=type

• Method: GET

• Allowed Roles: Employee or Admin or if the id provided matches the id of the current user

• Response:

  [
    Account
  ]

Submit Account

• URL: /accounts

• Method: POST

• Allowed Roles: Employee or Admin or if the account belongs to the current user

• Request: The accountId should be 0

  Account

• Response:

  • Status Code: 201 CREATED

  Account

Update Account

• URL: /accounts

• Method: PUT

• Allowed Roles: Admin

• Request: Note: All fields must be included

  Account

• Response:

  Account

Stretch Goals

These are not part of the core requirements but are things that could be worked on once the core requirements are done.

• Password Hashing
• Paging and Sorting endpoints: Reference For How
• Using JSON Web Tokens (JWTs) instead of Session Storage
• Standard Users should be able to upgrade to Premium (the cost of such an upgrade may be freely determined)
  • With this premium status, Users should now also be able to open new joint accounts (accounts with multiple owners), as well as be able to add users to pre-existing accounts
• Supporting DELETE requests for Users and Accounts
• Savings accounts will have interest rates, that can be determined as you see fit.

Pass Time

This endpoint is designed to simulate the passing of time for Savings Accounts to accrue interest

• URL: /passTime

• Method: POST

• Allowed Roles: Admin

• Request:

  {
    "numOfMonths": int
  }

• Response:

  {
    "message": "{numOfMonths} months of interest has been accrued for all Savings Accounts"
  }