Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interface types are documented as "Object" #561

Closed
lbndev opened this issue Dec 9, 2016 · 6 comments
Closed

Interface types are documented as "Object" #561

lbndev opened this issue Dec 9, 2016 · 6 comments

Comments

@lbndev
Copy link
Contributor

lbndev commented Dec 9, 2016

Working on #557 I noticed that when a method returns a data type that is an interface, it is simply shown as Object. Interface types should be documented the same way as abstract parent types.

@stoicflame
Copy link
Owner

Interfaces aren't data types, so Enunciate doesn't document them as such.

Maybe another way to say it is that there is no such thing as an "interface" in a Web service API. It's a construct specific to the language that doesn't translate to HTTP, SOAP, REST, XML, JSON, etc. So since Enunciate is documenting the Web service API, it's limited to the vocabulary of Web services and has no way of documenting an "interface."

@stoicflame
Copy link
Owner

See also #551.

@lbndev
Copy link
Contributor Author

lbndev commented Dec 9, 2016

Sure, but Java allows to define an interface type and use it as parameter or return type for services that Enunciate documents. So when I'm doing this :

public interface ISomething { }
public class SomethingImpl implements ISomething { }
public class AnotherImpl implements ISomething { }
@Path("/service")
public interface IService {
    @POST
    @Path("/execute")
    public ISomething doWork(ISomething input);
}

Enunciate shows parameter and return type of /service/execute as "Object" (or Array of Object if using a collection of ISomething). @typehint or @returnWrapped won't help : any implementation can be a valid value.
It is not always possible to change the interface to an abstract base class, so how can we document such services ?
My suggestion is to treat interface types as if they were abstract superclasses (dedicated page + as I added in my PR #562 : list of implementing types + warning message that this is "abstract").
Do you have another idea ?

@stoicflame stoicflame added this to the 2.8.0 milestone Dec 9, 2016
@stoicflame stoicflame reopened this Dec 9, 2016
@stoicflame
Copy link
Owner

stoicflame commented Dec 16, 2016

I started looking into this.

It's a reasonable idea, but it's quite a bit of work, so I'm pulling it off the release plan for now.

If anybody is willing to sponsor the work, reach out to me and I'd be happy to pick it up.

@stoicflame
Copy link
Owner

Thanks to the support of a generous sponsor, this issue has been implemented and will be included in 2.9.

@stoicflame
Copy link
Owner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants