Added behaviour endpoints #13
Conversation
| } | ||
|
|
||
| export interface BehaviourResponseDTO { | ||
| id: string; |
There was a problem hiding this comment.
should this be a number? I know that for the UserDTO the id is a string, but I think that might be because it's a firebase user ID. Not 100% sure about that though.
But I think if there's no use case difference of the DTO, between having it as a string versus a number, then we should keep it consistent with the DB and have it as a number.
| try { | ||
| behaviour = await PgBehaviour.findByPk(id, { raw: true }); | ||
| if (!behaviour) { | ||
| throw new Error(`Behaviour id ${id} not found`); |
There was a problem hiding this comment.
Do we want this to be a 404 NOT FOUND response? We could do this by making custom error types and handling them seperately in the behaviourRoutes.ts file. (Something like NotFoundError would work)
LOL sorry ik I'm nitpicking, but you're the first one that made endpoints so I wanna make sure some things are clear for others as well.
a. Getting all returns all behaviours in the database b. Getting a specific behaviour returns it if it exists c. Getting a specific behaviour returns 404 if it doesn't exist d. Creating a new behaviour returns the created behaviour and updates database e. Updating an existing behaviour returns the updated behaviour and updates database f. Updating a nonexistent behaviour returns a 404 and doesn't affect database g. Deleting an existing behaviour returns deleted behaviour's id and updates database h. Deleting nonexistent behavour returns 404 and doesn't affect database |
|
I also added the NotFoundError to the errorUtils file I found, but let me know if there's a better way to handle it. |
| if (e instanceof NotFoundError) { | ||
| res.status(404).send(getErrorMessage(e)); | ||
| } else { | ||
| res.status(500).send(getErrorMessage(e)); |
There was a problem hiding this comment.
for 500 i dont think we want to send the error message back. 500 is internal error so ideally we want to log the error internally, confirm @jerry-cheng5
There was a problem hiding this comment.
Yea I agree, I think that's the proper way to handle 500 errors.
(Normally its for security and shi and we don't reaaally have to worry about that, but its always good to practice the proper response conventions)
There was a problem hiding this comment.
So maybe just send some generic message back like:
An unexpected internal server error occurred. Please try again later.
or
An unexpected error occurred on our end. Please try again later.
There was a problem hiding this comment.
lgtm, wait for @laks0407 @jerry-cheng5 to take a final look
Created endpoints to modify/access the behaviour table.
Enabled getting all, getting one, creating, updating, and deleting entries.
Manually tested operations using Postman.