Open marloncarvalho opened 9 years ago
I think one possibility is that you create a class annotation (say ApiGroup
) that inherits from Group
and just interpolate the version
and the urlPrefix
onto the Group
super constructor. Example
@ApiGroup('/myPath', version: 'v1', strategy: 'header')
class AVersion1 {
@Route(path: 'myRoute')
MyObject get() { ... }
}
@ApiGroup('/myPath', version: 'v2', strategy: 'header')
class AVersion2 {
@Route(path: 'myRoute')
MyObject get() { ... }
}
The class should be defined something like
class ApiGroup extends Group {
final String version;
final String strategy;
const ApiGroup (String urlPrefix, {this.version: 'v1', this.strategy: 'header'}) : super ('/$version/$urlPrefix');
}
If you are really interested, I already have the GroupController
and DataController
in redstone_mvc
. The DataController
s are there help you with REST, although the only thing they do at the moment is convert the returned objects to JSON. I might be able to implement things into the plugin if you tell me what you are trying to accomplish.
Your approach is only one of two possible ways to control the API versioning. The strategy
attribute's goal is to control where the version data should be placed. It would be at the path like in /api/v1/resource
or at the Accept
header like in application/vnd.vendor.v1+json
. However, using your approach the version is going to be fixed at the URL. Agree?
Yesterday, I tried to create a Plugin to figure out whether it's possible or not to create a plugin like that. It turned out that Redstone doesn't allow us to have more than one route with the same path. Consider the example I gave in the first comment. In that example, Redstone only recognizes the routes defined in the class APIVersion2
. It ignores the first class or maybe (I'm guessing) it uses a Map and the path as key to this Map and thereby the first class APIVersion1
is replaced by the APIVersion2
.
Unfortunately, I think that to achieve my goal, Redstone may have to change some internal implementation.
Redstone uses the route_hierarchical
to route requests to methods/functions, much of what you see on how both Redstone and Angular manage routing, including route parameter specification style, is because they are based on this library. What you want makes sense given the http guidelines, but requires a routing mechanism that might be beyond what the routing library and redstone (at the moment) are capable.
I've been playing around with Redstone for a few days and my goal is to write a Redstone based RESTful API.
To accomplish it, I would like to create a simple mechanism responsible to handle API versioning. I'm thinking about creating an annotation like
@Version(version:'v1', strategy: 'header')
where the version attribute means theversion number
andstrategy
means where this version should be found (in this case, in theAccept
header).This annotation should be used at each class annotated with
@Group
(note that each route is gonna inherit this version). In that case, it's possible to have two or more classes with the same methods, same signatures and paths but belonging to different versions. Look at the two classes below.With that in mind, I should be able to decide, through a plugin, which route to call (from class
AVersion1
orAVersionB
). Finally, my question is: is it possible?