Oftentimes when looking to design a REST API I see a common pattern of /resourceA/{id}/resourceThatBelongsToA.
Is it ok to do /resourceA/resourcesThatBelongToA when designing an API?
Say I have a web application similar to StackOverflow. There are questions, and each question has a status of accepted or not accepted.
I expose an endpoint /questions/{id}/status so that users can determine whether or not a question has an accepted answer.
I then run into the problem of wanting to discover all questions that have an accepted answer. I then define an endpoint /questions/statuses?status=accepted. This endpoint, when given no query parameters, will list all the statuses of all questions (with reasonable limits on the amount of statuses return, say 100). However, when given a filter of status type, I can determine all questions that have an answer that was accepted.
To me, this seems like a practical design that fits the use case well.
Is this an acceptable pattern to use or is there something more suitable?
Is it ok to do /resourceA/resourcesThatBelongToA when designing an API?
Yes.
REST doesn't care what spelling you use for your identifiers. REST doesn't care how you organize your resource hierarchy.
Is this an acceptable pattern to use or is there something more suitable?
The heuristic I recommend is "would you do it this way with a web site?" If the answer is yes, then you are on the right track.