Intro to Backend Development
  • Introduction
  • SP25 Syllabus
  • Apply to Take the Course
  • Getting Started
  • Weekly Feedback Form
  • Ed Discussion
  • Intro to Backend SP25 Google Calendar
  • Cheat Sheets
    • Assignment Requirements
    • Assignment FAQs
    • Error FAQs 😢
    • Concept FAQs
    • Postman
    • Command Line
    • Virtual Environment
  • Chapters
    • 1. Routes
      • Pre-Class TODO's
      • Lecture
      • Assignment Handout
      • API Specification
    • 2. Databases
      • Pre-Class TODO's
      • Lecture
      • Demo
      • Assignment Handout
      • API Specification
    • 3. Relational Databases
      • Pre-Class TODO's
      • Lecture
      • Demo
      • Assignment Handout
      • API Specification
    • 4. Abstractions
      • Pre-Class TODO's
      • Lecture
      • Demo
      • Assignment Handout
      • API Specification
    • 5. Containerization
      • Pre-Class TODO's
      • Docker Installation
      • Lecture
      • Demo
      • Assignment Handout
    • 6. Deployment
      • Lecture
      • Demo
      • Assignment Handout
    • 7. Images
      • Demo
      • Assignment Handout
    • 8. Authentication
      • Lecture
      • Demo
      • Assignment Handout
    • (Work in Progress) OAuth
      • Pre-Class TODO's
      • Lecture
      • Demo
      • OAuth 2.0 vs OpenID
      • Flask / OpenID example
  • Additional Topics
    • Git and Github
    • HackOurCampus
  • Other AppDev Courses
    • Intro to iOS Development
    • Intro to Android Development
    • Intro to Digital Product Design
  • Deprecated
    • Previous Semester Syllabi
      • FA22 Syllabus
      • SP22 Syllabus
      • FA21 Syllabus
      • SP21 Syllabus
      • FA20 Syllabus
      • SP20 Syllabus
    • Deployment Pre-Class TODO's
    • PA6 Assignment Handout
    • Deployment Demo
    • Final Project (Spring 2019)
      • Final Project Award Winners
Powered by GitBook
On this page
  • Expected Functionality
  • Get all users
  • Create a user
  • Get a specific user
  • Delete a specific user
  • Create a transaction by sending or requesting money
  • Accept or Deny a payment request

Was this helpful?

  1. Chapters
  2. 3. Relational Databases

API Specification

Contributors: Alicia Wang, Conner Swenberg, Alanna Zhou

Values wrapped in < > are placeholders for what the field values should be. Also be sure to read the request route carefully when you implement it. Error responses should be provided as before.

Expected Functionality

Get all users

GET/api/users/

Response
<HTTP STATUS CODE 200>
{
    "users": [
        {
            "id" 1,
            "name": "Conner",
            "username": "cswenberg"
        },
        {
            "id": 2,
            "name": "Alicia",
            "username": "aawang"
        },
        ...
    ]
}

Note: Make sure not to include each user’s balance or transactions when getting all users - this would be a confidentiality issue in real life!

Create a user

POST/api/users/

Request
{
    "name": "Raahi Menon",
    "username": "raahi014",
    "balance": <USER INPUT (OPTIONAL INTEGER)>
}
Response
<HTTP STATUS CODE 201>
{
    "id": <ID>
    "name": "Raahi Menon",
    "username": "raahi014",
    "balance": <USER INPUT, OR 0 IF NOT PROVIDED>,
    "transactions": []
}

Get a specific user

GET/api/users/{id}/

Response
<HTTP STATUS CODE 200>
{
    "id": <ID>,
    "name": <STORED NAME FOR USER WITH ID {id}>,
    "username": <STORED USERNAME FOR USER WITH ID {id}>,
    "balance": <STORED BALANCE FOR USER WITH ID {id}>,
    "transactions": [
        <TRANSACTION>,
        <TRANSACTION>,
        ...
    ]
}

See the below routes for what data <TRANSACTION> should contain.

Delete a specific user

DELETE/api/users/{id}/

Response
<HTTP STATUS CODE 200>

<DELETED USER, INCLUDING BALANCE AND TRANSACTIONS, EXAMPLE BELOW>
{
    "id": <ID>,
    "name": <STORED NAME FOR USER WITH ID {id}>,
    "username": <STORED USERNAME FOR USER WITH ID {id}>,
    "balance": <STORED BALANCE FOR USER WITH ID {id}>,
    "transactions": [
        <TRANSACTION>,
        <TRANSACTION>,
        ...
    ]
}

Create a transaction by sending or requesting money

POST/api/transactions/

Request
{
    "sender_id": <USER INPUT>,
    "receiver_id": <USER INPUT>,
    "amount": <USER INPUT>,
    "message": <USER INPUT>,
    "accepted": true or null 
     // if accepted is null, record the transaction in database but don't update any balances
     // if accepted is true, update the balances if sender has sufficient funds
}
Response
<HTTP STATUS CODE 201>
{
    "id": <ID>,
    "timestamp": <NOW>,
    "sender_id": <USER INPUT FOR SENDER_ID>,
    "receiver_id": <USER INPUT FOR RECEIVER_ID>,
    "amount": <USER INPUT FOR AMOUNT>,
    "message": <USER INPUT FOR MESSAGE>,
    "accepted": <USER INPUT FOR ACCEPTED>
}

Accept or Deny a payment request

POST/api/transactions/{id}/

Request
{
    "accepted": true or false
}
Response
<HTTP STATUS CODE 200>
{
    "id": <ID>,
    "timestamp": <NOW>,  // update timestamp to time of accept/deny
    "sender_id": <USER INPUT FOR SENDER_ID>,
    "receiver_id": <USER INPUT FOR RECEIVER_ID>,
    "amount": <USER INPUT FOR AMOUNT>,
    "message": <USER INPUT FOR MESSAGE>,
    "accepted": <USER INPUT FOR ACCEPTED>  
}

If accepted is currently None and the post body request's new accepted is True, check if the user has enough money in their balance. If this is satisfied, then update the transaction's accepted to be True and update the balances. If the user does not have enough money in their balance, return an error response with status code 403 (forbidden) and a relevant error message saying this.

If accepted is currently None and the post body request's new accepted is False, update the transaction's accepted to be False.

If accepted currently has some value, be it True or False, then return an error response with status code 403 (forbidden) saying that you cannot change transaction's accepted field if the transaction has already been accepted or denied.

PreviousAssignment HandoutNext4. Abstractions

Last updated 27 days ago

Was this helpful?

Note: If the accepted field is true, then carry out the transaction. This means that if the transaction amount is more than the sender's balance, return an error response with status code 403. In the case of creating a payment request, the sender_id refers to the id of the user that will eventually send the money. Therefore, the receiver_id is the id of the user making the request for money. For help with timestamp, look into the .

datetime library