Use a superinterface to define methods on @Rest interfaces #339
Comments
I definitely agree with this one, I'm running into the issue now. I have a shared method which will set the authentication on my rest services, but I need to pass in an Object and use reflection to find the methods instead of just using an interface. |
I agree with the feature proposed by @pyricau. This could be less confusing. @rockytriton > I don't really understand your use case. Why do you need reflection ? |
Because he wants to call setRestTemplate on all his @rest services, and they have no interface in common, I guess.
Why would you use more than 1 interface if every generated rest clients implement them all anyway ? |
I have an app that uses several different REST services. I have a method which sets the basic authentication on them all and also a method which changes the service URL (you can configure which server to point to). I would like to pass the service object to these methods using more than one service class, hence why I would use an interface that they all implement. |
What do you all think about his.
This will greatly simplify the validation code for one thing. We would simply not allow any non-annotated methods. Unless of course you wanted to have backward compatibility but with all of the package name changes, this would be the time to redo things since they would have to edit all of their code anyway. Another option would also be to add another interface IBasicAuth which would have methods for setting user/pass when using basic authentication. Just a simpler way to add the auth code, it could be implemented in the generated code as well. |
It seems good. |
I agree with you on the Ixxx naming convention, but it's really just a matter of preference, I've worked at many clients over the years where they feel very strongly one way or the other, but really it just comes down to preferences and how they do their naming standards in the organization. I like the name you came up with. What do you think about making the errorHandler method you mentioned in #623 a part of this interface as well? Or did you think it would be better as a separate interface? Personally I think it makes sense to have it all in the same interface. What do you think about set/getErrorHandler methods instead? There's also the option to have an addErrorHandler so that it supports multiple handlers and to be more consistant with many java API classes, though I don't think it would really be necessary to support multiple but who knows what other people may need. |
Since #579 has been merged we have 5 more specific methods to handle. I think it's time to categorize them and create multiple interface. Here is a proposal for the full list of methods :
|
I was thinking about this too, but I couldn't figure out two different interfaces that made enough sense. Really the restTemplate and rootUrl don't have anything in common. I suppose that the cookie/header/auth do have the fact that they are all related to http headers in common. I think it would make sense to either put them all in a single "Enhanced" interface or to also split the restTemplate and rootUrl into their own interface. Personally I think it's fine to just put them all in a single interface, it's not like adding the code that may or may not be used would have any detrimental effect on performance or anything like that. Really all the methods have in common that they represent an enhanced interface to the rest client. Either way though I'm fine with separating them out too, just let me know what you think. I think I already have something working well with these changes, I just need to add more comments and some unit tests. Also I did a little bit of refactoring to the RestProcessor code to increase re-use and make smaller methods (I hope that's ok). |
Also, don't forget the setErrorHandler (or whatever it should be called) method. |
What do you think about this: One single interface: interface RestClientSupportHook { One single abstract class: abstract class RestClientSupport { Then, the generated client class should extends the Abstract class, and @rest Generates: class MyRestClient_ extends RestClientSupport implements MyRestClient { And finally can be used as: @restservice service.getRestClientSupport().setRootUrl(....); On Sat, Jul 13, 2013 at 1:10 PM, Rocky D. Pulley
Frank D. Martínez M. |
@mnesarco > I think it's just overkill to do it that way. We could just let the user implement the interface and AA will generate the proper code. @rockytriton > Yep. I forgot to add With that in mind I propose this :
|
I like this idea of logically grouping them together. |
I keep this one open until we update the wiki. |
Is there some Magic required to get my headers i set with if i look at the generated code, there is a
same for i use 3.0-SNAPSHOT |
okay, just found the @RequiresXXX Annotations while trying to "fix" my issue mentioned in the comment... |
Documentation has been updated. Please let me know if you see mistakes. |
I think the In this example your code should call |
Fixed. Thanks for review 👍 |
Extracted from #207
We currently "detect" some methods on
@Rest
annotated interfaces, and implement them if needed.Instead of that, we should force the users to let their interface extend another interface that has these
setRestTemplate()
etc methods defined, and always implement it in the generated class.The text was updated successfully, but these errors were encountered: