Asp.Net Web Api：处理两个具有相同签名的获取请求

Question

Current situation

    [HttpGet]
    public HttpResponseMessage CheckProfileStatus(int id)
    {
        //check profile status from third party
        return //profile status and HttpStatus;
    }

    [HttpGet]
    public HttpResponseMessage ProcessTheProfile(int profileId)
    {
        //check profile status from third party again, if status is "Good", do something
        return //someMessage and HttpStatus;
    }

Url to call CheckProfileStatus method

myUrl/api/Profile/123

Url to call ProcessTheProfile method

myUrl/api/Profile/?profileId=123

I hope the comments in the code makes the situation clear.

I don't really like the fact that I have two HttpGet methods with same signature in one controller (even though it works).

I don't know if it is best practice.

Question:

Should I extract these two methods in two seperate controllers, is it completely fine to have two HttpGet methods with same signature in one controller or is there better way to handle this situation?

Answer 1

First, this is confusing to any client of the API.

You have 2 GET methods which are virtually identical. In fact most people prefer to add a route covering your first option which basically sets the profileId to the value after the forward slash.

Second, the expectation is that when you issue a GET against an entity with an ID, you get the representation of that entity. This is not what's happening here.

You need to decide which kind of API do you want. A generic one where stuff like this is fine :

myUrl/api/profile/process/123 or process/profile , or whatever else makes sense to the API.

If your API is supposed to be RESTful ( which basically means you will have one method per HTTP verb and nothing more ) then you need to add a new controller for ProcessProfile and then your url can look like this :

myUrl/api/ProcessProfile/123

None of these options is set in stone, they are just that, options. The comments to the OP thread give some good options as well, which should be considered.

Answer 2

In my opinion, this approach will cause problems if your project grows bigger since it's confusing to use.

I would suggest that you use a RESTful approach.

Maybe this article will help you a bit in understanding.

https://medium.com/@schneidenbach/restful-api-best-practices-and-common-pitfalls-7a83ba3763b5