Under the current logic, the association Resources are named according to the model name, inflected for the number of the association. I think with my example here, we would get /courses/:id/person and /courses/:id/people/. Intuitively, though, it seems like we have gone to the trouble of naming the association in the model, and so we should get routes like /courses/:id/students/ and /courses/:id/teacher.
This patch checks the association.as field before setting the subResourceName.
I think it makes sense to be able to decide what the
subResourceName
of an association is. For instance, imagine that I have:Under the current logic, the association Resources are named according to the model name, inflected for the number of the association. I think with my example here, we would get
/courses/:id/person
and/courses/:id/people/
. Intuitively, though, it seems like we have gone to the trouble of naming the association in the model, and so we should get routes like/courses/:id/students/
and/courses/:id/teacher
.This patch checks the
association.as
field before setting thesubResourceName
.