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
  • Send money from one user to another

Was this helpful?

  1. Chapters
  2. 2. Databases

API Specification

Contributors: Alicia Wang, Conner Swenberg

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.

NOTE ABOUT ERROR RESPONSES

The server should return an error response for:

  • POST requests, if the user does not supply one of the fields in the body (e.g. name, username, etc.) with a status code of 400 (bad request)

  • GET , POST and DELETE requests, if the requested resource in the URL does not exist, with a status code of 404 (not found)

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",
        },
        ...
    ]
}

Make sure not to include each user’s balance 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": <OPTIONAL INTEGER>
}
Response
<HTTP STATUS CODE 201>
{
    "id": <ID>
    "name": "Raahi Menon",
    "username": "raahi014",
    "balance": <USER INPUT or DEFAULT TO 0 IF NOT PROVIDED>
}

If the user does not supply a name, a username, or both, you should return a failure response with a descriptive error message

You can give a default value of 0 for a key that does not exist for a dictionary like so: body.get("balance", 0)

Get a specific user

GET/api/user/{id}/

Response
<HTTP STATUS CODE 200>
{
    "id": <ID>,
    "name": <STORED NAME FOR USER {id}>,
    "username": <STORED USERNAME FOR USER {id}>,
    "balance": <STORED BALANCE FOR USER {id}>
}

Delete a specific user

DELETE/api/user/{id}/

Response
<HTTP STATUS CODE 200>
{
    "id": <ID>,
    "name": <NAME OF DELETED USER WITH ID {id}>,
    "username": <USERNAME OF DELETED USER WITH ID {id}>,
    "balance": <BALANCE OF DELETED USER WITH ID {id}>
}

Send money from one user to another

POST/api/send/

Request
{
    "sender_id": <USER INPUT>,
    "receiver_id": <USER INPUT>,
    "amount": <USER INPUT>
}
Response
<HTTP STATUS CODE 200>
{
    "sender_id": <USER INPUT FOR SENDER>,
    "receiver_id": <USER INPUT FOR RECEIVER>,
    "amount": <USER INPUT FOR AMOUNT> 
}

A sender should not be able to overdraw their balance! If a request comes in where the sender sends more money than they have, you should return an error with 400 status code.

If the client does not provide a sender_id, receiver_id, amount, or any combination of those, respond with a descriptive error message and a 400 status code.

When checking if the user actually sent in a sender_id, you should check if sender_id is not None, instead of not sender_id. This is because the number zero is a false-y value, which means not sender_id will return True, even though the user did supply an id, albeit a value of zero. If this is still confusing, consider using bool() in a Python shell:

>>> bool(None)
False

>>> bool(1)
True

>>> bool(0)
False

PreviousAssignment HandoutNext3. Relational Databases

Last updated 1 year ago

Was this helpful?