However, it seems strange to me that you run into CSRF issues. Did you really use the same code and retry or did you register two ropes and copy the code over? The CSRF check should be independent of and routing issues and only checks for the annotation/attribute @NoCsrfCheck.
So, if I understand, if I want to have the /spaces?search={name} route. I must write /spaces and define the parameter on the front-end side ?
However, I cannot have 2 routes with /spaces. I have to keep this route :
But, Does it make sense to have one single route (/spaces) to get all workspaces or one workspace with the search as parameter (example : /spaces?search={name}) ?
Phew, I am not sure what will happen there. I would have to dig into the routing routines in the server to understand that in detail. At least, I was careful as this is not done as documented.
I am not sure, I get your point. You will always have to adopt the frontend to the backend. So, yes this is always true that you must add the parameters in the frontend in some way…
This might be discussable. Does it make sense? You could have a /spaces for all spaces and /search/{name} or /search?q={name} or /spaces/search?q={name} or anything else that can be uniquely distinguished. That might be a bit cleaner in terms of API anyways. You can still call similar service methods in the backend to avoid duplicate code.
If you really want to do things in one controller method, you could add an optional parameter name in the query string and give it a default of e.g. null. Then, you can check in the method for null (return all entries). If it is non-null, carry out the requested search.