Create REST API for ResponseConstraint resource

[tylerthome]

Overview

Create a REST API handling add, update, retrieval and delete operations on the response constraint resource.

Action Items

Add HTTP stubs to server source code

• Retrieve all constraints by location ID
  • method: GET
  • route: /api/locations/{locationId}/constraints
  • accepts: Location ID (integer or uuid)
  • returns: JSON array of ResponseConstraint objects (described below)
• Add constraint
  • method: POST
  • route: /api/locations/{locationId}/constraints
  • accepts: JSON payload containing ResponseConstraint object
  • returns: HTTP response with status 200, 400 or 500 depending on result of operation
• Update constraint information by ID
  • method: PUT
  • route: /api/locations/{locationId}/constraints/{constraintId}
  • accepts: JSON payload containing ResponseConstraint object
  • returns: HTTP response with status 200, 400 or 500 depending on result of operation
• (Bonus) Update constraint information attribute by constraint ID
  • method: PATCH
  • route: /api/locations/{locationId}/constraints/{constraintId}
  • accepts: JSON Patch payload for a ResponseConstraint object
  • returns: HTTP response with status 200, 400 or 500 depending on result of operation

Resources/Instructions

• Use or improve upon the following data model for the JSON payload:

ResponseConstraint:
    locationId: integer
    questionId: integer
    acceptedValues: Array<string | integer | boolean>
    constraintId?: integer

• Make use of Flask's declarative route definition syntax to specify URIs

[kkchu791]

For the data model

ResponseConstraint:
    locationId: integer
    questionId: integer
    acceptedValues: Array<string | integer | boolean>
    constraintId?: integer

is the constraintId supposed to have a question mark?

Also, is this what the JSON might look like for one response constraint?

response_constraint = {
  id: 1,
  locationId: 1,
  questionId: 1,
  acceptedValue: ["no", "nope", "i don't like pets"],
  constraintId: 1

If this was a relational model, i would see it as

LocationTable {id: 1, location: "LA family housing building"}

QuestionTable {id: 1, question: "Do you like pets?"}

ResponseConstraintTable

{
  id: 1,
  locationId: 1,
  questionId: 1,
  acceptedValue=["no", "nope", "i don't like pets"]
}

With what I've seen from the looking at models/sqlalchmey/model.py, I see the associations as:

Each question will have many constraints (I think we're talking about choices here).

A question can also have many responses (think multi select here),

These responses are tied to a specific choice or constraint, hence response constraint?

Do i have this correct? Is there an entity relationship diagram I could follow?

[tylerthome]

For the first version, we have made these assumptions:

• Question will define a finite set of ResponseValues which are considered valid answers to the question
• A Candidate will submit exactly one ResponseValue. Keep in mind, these don't have to correlate one-to-one with the displayed choices. We could define a ResponseValue that represents "no response / unknown", or combinations of multi-select answers like "dog, bird" as a distinct ResponseValue from "dog" and "bird"
• A HousingLocation can specify ResponseConstraints, which specify which of the ResponseValues a HousingLocation will accept for a given Question.

Therefore the QuestionTable JSON needs to be modified:

{id: 1, question: "Do you like pets?", responseValues: ["yes", "no"] }

and the ResponseConstraint might look like

{
  id: 1,
  locationId: 1,
  questionId: 1,
  acceptedValues=["no"]
}

...as the acceptedValues must be from the responseValues in the question. These could be modeled with IDs to reference for more consistency, but strings will work for now, since the UI will be in control of which ResponseValues a user can choose from for the ResponseConstraint.

With regard to constraintId, I used the "?" notation to convey that this value will be null during certain states in the application. When a user is in the 'Add Constraint' UI creating a new ResponseConstraint for a particular HousingLocation, the ResponseConstraint instance will not have an ID, because it has not been assigned by the DB. This allows the user to Cancel the 'Add Constraint' operation and the DB's state is unchanged (as opposed to acquiring a new ID before presenting the UI, in which case some DB state has changed for no reason if the operation were canceled).