WebAPI Client Proxy

I'm working on a client proxy for my WebAPI. I've looked at WebApiProxy but I feel DTOs are unnecessary in my scenario.

I made an ApiProxyBase class that supports basic Get, Post, Put and Delete functionality using generics. Using this base class I've setup an implementation as follows:

public sealed class MyProxy : ApiProxyBase
{
    private static readonly string ConnectionString = "MyServiceUrl";
    private static readonly MyProxy Instance = new MyProxy(InitializeConnection());

    private MyProxy(string url) : base(url)
    {

    }

    private static string InitializeConnection()
    {
        var conn = ConfigurationManager.ConnectionStrings[ConnectionString];
        if (conn == null) throw new InvalidOperationException("MyProxy requires a connection string with the name '" + ConnectionString + "'");
        return conn.ConnectionString;
    }

    public static class Users
    {
        public static List List()
        {
            return Instance.Get>("users/list");
        }

        public static User Single(int userId)
        {
            return Instance.Get("users/" + userId.ToString());
        }

        public static User Add(User user)
        {
            return Instance.Post("users/add", user);
        }

        public static User Update(User user)
        {
            return Instance.Put("users/update", user);
        }

        public static bool Delete(int userId)
        {
            return Instance.Delete("users/delete/" + userId.ToString());
        }
    }
}

I've read that public nested classes such as this are considered bad practice. To me it feels much cleaner and more readable than implementing each method directly in the proxy like this:

public static List ListUsers()
{
    return Instance.Get>("users/list");
}

I plan to add more nested classes for each of the datatypes I need, so the semantics of MyProxy.[Type].Add, MyProxy.[Type].Update...etc. feels very smooth when compared to `MyProxy.Add[Typ

The drawback to this is that you couple two classes together based on an arbitrary property of the outer class named Instance. Also, if you need to write tests around this you will run into issues. I would either make a singleton class for your proxy or instantiate the proxy at application start and make it a property of the application. You'll get the same benefits as your current approach.

If you feel intermediary DTOs are unnecessary, then you have a choice on how the objects you do work with get created which defines how you will deal with breaking changes:

• If you go with the implementation you're using and everything is written manually by you, when something changes, you fix it by going in and write new objects/props.

• If you use the client generator that you linked, you still have the option of referencing it directly and not making a middle layer. Then when something changes, you go in, regenerate your client, and fix any compile-time errors.

I think the latter sounds easier to me.

StackExchange Code Review Q#92078, answer score: 2