Rest API architecture special cases - rest

Question

Using the Web API in .net 5 and conforming an api in rest gives me some challenges about how much to split up the methods in different controllers and the naming conventions.
I have read that if I have users in my system and doing a rest architecture, my controller would be named UserController and method for getting a user would be:
[HttpGet("{id}")]
public string Get(int id)
{
return "value";
}
For getting a list of users it would be:
[HttpGet]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
Updating would be:
[HttpPut("{id}")]
public void Put(int id, [FromBody] string value)
{
}
Delete would have a [HttpDelete], and so on. But what about the special cases?
What if I wanted GetUserByUsername? Would it then be in the same UserController and just be the following, or would it break the REST pattern?:
[HttpGet("{username}")]
public Task GetByUsername(string username)
{
}
What if I needed a call to the api get some data to populate the "createuser page", lets say I need the roles that the user could be created as and some other information and would like to do it in one call. Could I then just create a "InitCreateUser" in the UserController and not break the REST pattern?
[HttpPost]
public Task InitCreateUser()
{
}
What if I needed Login and Logout methods, would it be AutenticationController and just have the two methods: (It's just so far from the other pattern when its not called just Get() Post() and so on)
[HttpPost]
public Task Login(LoginRequest request)
{
}
[HttpPost]
public Task Logout(LogoutRequest request)
{
}

Answer 1

Yes you would put it in the same controller as it is still dealing with the user, and it is good habit to keep functions involving a specific entity in the same location.
But that obviously has the issue of having different endpoints such as Id and Username. A simple way to do this is to indicate which you want to use:
[HttpGet("Id/{id}")]
public string Get([FromRoute] int id) {...}
-> api/User/Id/293
[HttpGet("Username/{username}")]
public string Get([FromRoute] string username) {...}
-> api/User/Username/Tom
Another way is to have a base request and have other functions be offshoots of it
[HttpGet("{id}")]
public string Get([FromRoute] int id) {...}
-> api/User/293
[HttpGet("Username/{username}")]
public string Get([FromRoute] string username) {...}
-> api/User/Username/Tom
[HttpGet("Customer/{custNo}")]
public string Get([FromRoute] string custNo) {...}
-> api/User/Customer/5DtU22D
But lets say you have the Id of the user and you wish to do other functions like get relevant data from the user to display, but not all of it. Or You want to check all the relating data towards a specific funciton,
then you can do something like this:
[HttpGet("{id}/Permissions")]
public PermissionModel GetUserPermission([FromRoute] int id) {...}
[HttpPut("{id}/Permissions")]
public bool UpdateUserPermission([FromRoute] int id, [FromBody] PermissionModel permission) {...}
Or even further derived functionalities
[HttpGet("{id}/Account")]
public string GetUserAccount([FromRoute] int id) {...}
[HttpGet("{id}/Account/Funds")]
public double GetUserAccountTotal([FromRoute] int id) {...}
if you are accessing list properties, for example the user has many accounts for example, you can add a secondary key:
[HttpGet("{id}/Accounts")]
public IEnumerable<string> GetUserAccount([FromRoute] int id) {...}
[HttpGet("{id}/Accounts/{accountId}/Funds")]
public double GetUserAccountTotal([FromRoute] int id, [FromRoute] int accountId) {...}