Add read endpoints #11
Conversation
feliciagan
commented
Sep 21, 2024
feliciagan
commented
- implement endpoint to read questions for question list (with filter and search functionality).
- implement endpoint to read question using specific question id.
-implement endpoint to read questions for question list (with filter and search functionality) -implement endpoint to read question using specific question id
| @@ -10,4 +12,8 @@ router.post("/questions", createQuestion); | |||
|
|
|||
| router.put("/questions/:id", updateQuestion); | |||
|
|
|||
| router.post("/questionsquery/:currPage", readQuestionsList); | |||
There was a problem hiding this comment.
should it be a GET request? since we are reading and not creating questions
There was a problem hiding this comment.
hmm will get be enough for sending the conditions to search and filter by
There was a problem hiding this comment.
like if the search string is very long and the person filter by many conditions
There was a problem hiding this comment.
oh i think the length of the query shouldnt affect anything? the conditions can be specified as a list i think
There was a problem hiding this comment.
doesnt the url hv a length limit though?
There was a problem hiding this comment.
Ohh I think I get your concern, I was searching up on this and some do suggest using POST instead of GET to handle the case of queries with long params (not sure if it's good practice though)
I feel like it's quite unlikely to hit the URL length limit (around 2k characters?) But if we really want to be safe, alternatively we can either
- restrict the length of query params in the frontend (eg. character limit on the search keyword)
- do error handling in the backend (catch 414 and have the frontend display something similar to page not found)
There was a problem hiding this comment.
hmm alright i'll change to GET, then it might be better to restrict search character limit + filter categories in the frontend? (i'll still catch 414 just in case but i think just catch 414 only is abit late, like we let the user query with so many conditions already then we tell them that we can't search with that many.)
is that ok?
There was a problem hiding this comment.
wait is it possible for you to check if the url too long on the front end instead
There was a problem hiding this comment.
I think yes but hmm what do we show the user if the url is too long? I think like what you mentioned it's better not to let the user submit a very long query then only inform them that it's too long right
I can do the character restrictions for the search and filter parameters in the frontend if that helps~
There was a problem hiding this comment.
yea i think if we can guarantee that url will never be too long with restrictions we can forgo the url too long check? otherwise we probably have to put error message like "too many keywords pls try with less" cuz if we just return server error they might try the same thing again.
- changed getting the question list from using POST request to using GET request - allow frontend to specify question limit per page through request query
| try { | ||
| const { page, qnLimit, title, complexities, categories } = req.query; | ||
|
|
||
| if (!page || !qnLimit) { |
There was a problem hiding this comment.
should we set a default if the user doesn't specify? maybe fetch the first page containing 10 questions
There was a problem hiding this comment.
would it be better for the frontend to handle the error message returned and resend the correct request instead? cuz if not then the user click to go to pg 11 then they go back to pg 1 also a bit weird. also on that note im not sure if this error will actually happen cuz the frontend shld always be sending it correctly?
There was a problem hiding this comment.
@ruiqi7 what do u think? since u doing the frontend
There was a problem hiding this comment.
I think yes, the frontend will be sending it properly
- add endpoint for reading unique question categories for frontend filter component - update api documentation
- return total number of questions instead of pages
