Progettazione dell'architettura dell'API Web

La stai complicando in questo modo.

Le API Web sono progettate per consentirti di scrivere il codice del tuo controller in modo "naturale" il più possibile. Il tipo di ritorno IHttpActionResult è principalmente inteso come un tratteggio di escape quando si desidera la massima flessibilità.

Ecco come scriverei il tuo metodo:

public ClrObject1 Method1(string arg1 = null, string arg2 = null, string arg3 = null)
{
    ClrObject1 varClrObject = (from p in db.clrObject1
                               where p.column1 == arg1
                               select p).SingleOrDefault();

    if (varClrObject == null)
    {
        // This line will automatically return a 404 error to the user.
        throw new HttpResponseException(HttpStatusCode.NotFound);
        // If you want, you can also build a full HttpResponseMessage
        // to give more details about the error.
    }

    // Web API will automatically return serialize and return your object
    // in a 200 OK response.
    return varClrObject;
}

Noterai che non metto un blocco di try - catch per gestire le eccezioni - il motivo è che, se un'eccezione viene sollevata e non gestita, verrà restituito all'utente un errore 500, che di solito è quello che voglio. Inoltre, non si desidera sempre restituire dettagli sulla propria eccezione nella risposta HTTP, in quanto tali informazioni potrebbero rivelare informazioni che potrebbero essere utilizzate per aiutare l'hacking del server delle applicazioni.

Sono d'accordo con @jhominal che stai rendendo questo modo più complicato di quanto debba essere. Innanzitutto, l'azione deve restituire un'istanza concreta di un oggetto. La ragione di ciò è di consentire al framework API Web di eseguire la negoziazione del contenuto tra JSON e Xml senza troppi problemi. Se non ti devi preoccupare di questo e puoi scegliere tra l'uno o l'altro, puoi usare un'interfaccia per il tuo oggetto (che è in genere ideale), ma non hai bisogno di un HttpActionResult perché quando esegui un entrare nell'API Web stai cercando una risorsa specifica e quella risorsa dovrebbe avere un tipo. Qualsiasi cosa che non restituisce una risorsa dovrebbe restituire un HttpResponseMessage formattato correttamente che è più facilmente gestito attraverso un HttpResponseException . Incollerò uno snippet qui sotto con i commenti per descrivere come mi piace creare azioni del controllore:

// I always specify the http verb that the method is 
// intended to respond to. It's extremely rare that
// multiple verbs should perform the same actions in
// an API. Also, I'm not a big fan of using optional
// parameters in this manner. I much prefer to use a 
// common get action and then pull the arguments like
// this from the RequestUri. It helps keep my routes
// nice and clean
[HttpGet]        
public MyCustomObject Post(string arg 1= null, string arg2 = null, string arg3 = null)
{
    // Perform validation of arguments as necessary
    // If it's not necessary, then skip this
    if (string.IsNullOrWhiteSpace(arg1))
    {
        throw new HttpResponseException(Request.CreateErrorResponse(
            HttpStatusCode.BadRequest,
            "I need to be supplied with arg1."));
    }

    // I prefer to send a request with relevant data to 
    // a rules engine/library of some sort that returns 
    // a formatted response (very similar to your
    // ReturnMessages object
    var response = MyRules.PerformQuery<MyCustomObject>(arg1, arg2, arg3);

    // Just as your ReturnMessages I use a status code
    if (response.Code == ResponseCode.Success)
    {
        return response.Entity;
        // In my preferred architecture, response.Entity is a
        // generic type, in this case MyCustomObject as above
    }

    // If you get to this point, something has gone wrong.
    // You can add additional logic before or after your
    // call to deliver this response message. The arguments
    // necessary are a property HttpStatusCode (any code)
    // and a valid response message string.
    throw new HttpResponseException(
        Request.CreateErrorResponse(response.Code, response.Message));
}

Quindi, per riassumere, cerco di mantenere la mia architettura il più semplice possibile. Le sue ossa sono la convalida dell'argomento, una chiamata a un motore di regole, una risposta all'oggetto concreto e quindi casi di eccezione. Aiuta a mantenere l'azione del controller fornendo risposte HTTP adeguate rispetto a risorse e messaggi.