Composing multiple interfaces for one API. about refit HOT 14 CLOSED

This isn't possible right now, the best you can do currently is use partial classes (Partial interfaces? Is that a thing?) The idea of nesting objects is kind of interesting though

from refit.

Yeah. I'm new to this library, and i'm experimenting with it. Maybe one singe big interface is a better solution, having all the endpoints in one place, it's easier to navigate and understand. I'll play around more. Thanks.

from refit.

It seems reasonable for interface-returning properties on API interfaces to return Refit proxies for the returned interface.

from refit.

I've begun adding support for it (see here).

Currently, a refit interface can be composed of other refit interfaces like this:

public interface IServicePart
{
   [Get("/")]
   Task<List<string>> GetUsers();

   [Get("/{user}")]
   Task<string> GetUser(string user);
}

public interface IService
{
   [Compose("/users")]
   IServicePart Users { get; }

The attribute is mandatory here, unless we have all the compile time types (requiring another part of Roslyn).
Of course, we can compose multiple interface, even generic interfaces.

What do you think of it ?

from refit.

I'm not opposed to it but I'm not sure we need the compose attribute to generate the stubs - as long as all of the interfaces you're composing are in the same project, you should be able to pick up any wrapper interfaces with a second pass:

1. Run through interfaces and detect all Refit interfaces (as we currently do)
2. Run through interfaces again and look for any that have properties which are in the first list

We could run into problems without an attribute though, because it would mean having to pass the relative paths in when calling RestService.For() which could get a little clunky. I think I prefer the attribute.

@paulcbetts?

I think it looks good so far. What else is there still to do on it (other than tests)? I think anything that we're building into the stubs that will throw an exception should raise a warning at build time too, so you'll want to do that as soon as we get #79 merged.

from refit.

Am I understanding the semantics right here?

public interface IServicePart
{
   // Actually makes a request to /users
   [Get("/")]
   Task<List<string>> GetUsers();

   // Actually makes a request to /users/{user}
   [Get("/{user}")]
   Task<string> GetUser(string user);
}

public interface IService
{
   [Compose("/users")]
   IServicePart Users { get; }
}

How is this better (this is not a rhetorical question, it very may well be!) than:

public interface IService
{
   IServicePart Users { get; }
}

public class Service 
{
    IServicePart Users {
        get { return RestService.For<IServicePart>("https://myservice.com/users"); }
    }
}

from refit.

It still allows you to have refit method inside your interface and compose it.

This will work:

public interface IServicePart
{
   // Actually makes a request to /users
   [Get("/")]
   Task<List<string>> GetUsers();

   // Actually makes a request to /users/{user}
   [Get("/{user}")]
   Task<string> GetUser(string user);
}

public interface IService
{
   [Compose("/users")]
   IServicePart Users { get; }

   [Get("/")]
   Task<List<string>> Get();
}

Maybe it is too much and interface composition shouldn't be mixed with refit service definition.

from refit.

How is this better (this is not a rhetorical question, it very may well be!)...

I think it's potentially worse actually - you lose the control over the HttpClient that you get with a direct call to RestService.For<IServicePart>(someClient).

If we go ahead with it, we will need to make sure we allow for a single HttpClient instance to be shared by all nested calls to RestService.For(), which could get complicated.

from refit.

Sorry, accidentally clicked the button.

from refit.

I think you could just do this better with Extension Methods:

public interface IService
{
   [Get("/")]
   Task<List<string>> Get();
}

public static class UsersExtension
{
    public static IServicePart Users(this IService This) {
        return RestService.For<IServicePart>("https://myservice.com/users");
    } 
}

from refit.

Looks good.
You lose the garantee that both services will use the same base address but it will probably be easier to use.

Currently, I don't have [Header(...)] inheritance in sub-service, so you have to specify it everywhere.
If it isn't needed, no need to support the whole sub-service generation.

from refit.

Let's close this out then, unless someone comes up with a super cool use-case

from refit.

Maybe we could update the Readme to include your solution ?

from refit.

@nekresh Can you submit a PR to do that?

from refit.