I would even go further on this case, have the web server extract the
api version and proxy to the correct app instance.
Of course it may use a bit more server resources but the ease of
deployment and bug fixes (in each supported version) is so high, and no
more 'if's ;-)
(Just thinking out loud)
Regards,
Le 20.09.12 04:51, Ben Willis a écrit :
I see your point Ryan, but if you have different code paths for
different versions the 'if' logic has to go somewhere. Most of the
other approaches will push the conditional into your routes file which
makes it more difficult to dry your controller logic. Ideally you do
not need to have these code paths at all and the only thing changing
is the view of the payload.
On Wed, Sep 19, 2012 at 6:28 PM, Ryan Bigg <[email protected]
<mailto:[email protected]>> wrote:
This seems a bit hacky. I don't like the idea of having
conditionals in your controller actions to determine different
code paths. That feels a bit like the olden days in PHP-land.
On Thursday, 20 September 2012 at 2:26 AM, Jim Jones wrote:
Thanks for the feedback guys.
> In my experience, however, it's usually more than just the view that
changes between versions.
The controller receives customizations as well, sometimes.
Therefore, I think that versioning the views is not a "majority
case" and shouldn't be a core feature.
Ryan, we've updated our samples to show how changes to your API
logic (per version) can be accounted for in your controllers to
ensure backwards/forwards compatibility :
class PostsController < ApplicationController
def index
# shared code for all versions
@posts = Post.scoped
# version 3 or greated supports embedding post comments
if requested_version >= 3
@posts = @posts.includes(:comments)
end
end
end
It's just a simple comparison against the view version.
The beauty of the view based APIs is that they allow you to
easily reuse your existing controller logic. Separating of API
logic into their own controllers doesn't have that advantage.
So our solution covers both the controller, allowing you to make
exceptions to ensure forwards/backwards compatibility by simply
checking against the current version (please see our updated
examples) and then the aforementioned view version with
degradation support.
Jim Jones
http://www.github.com/aantix
On Sunday, September 16, 2012 1:46:34 PM UTC-7, mrloz wrote:
I just wanted to chime in a second.
I agree this versioning is a little niche.
Is there, however, a neat public API in rails for gem authors to
add in lookup match parts for view lookup?
I.e is it possible to register (:apiversion) into lookup paths
and have it be handled by my class (ApiVersionPathHandler).
Similar to the current .format and .locale stuff in view file names
For me it might be about other things (regions, roles whatever
my gem wants to provide)
I am under the impression that these parts are not open to
extension at present.
Cheers
Sent from my iPhone
On 16 Sep 2012, at 21:21, Ryan Bigg <[email protected]> wrote:
[This email will arrive approx 15 hours after I've written it.
Sorry if there's been talk on this post by that stage that I am
"ignoring"]
I'm not sure I can agree with such a feature being a part of
Rails just yet. There is currently many different approaches to
designing APIs with Rails, going from the very basic "render
JSON" calls in the controllers, to rabl and (god forbid, only
because the syntax is really ugly) JBuilder, to
ActiveModel::Serializers and not to forget the new Rails::API
gem thing that Santiago Pastorino and co are working on.
My point is that there's all these different ways to do the
design of the API and, besides the default render call, none of
these are core Rails features. They're all external gems that
offer their unique take on how to "properly" design an API.
I can definitely see how, in a very small use case, versioning
the views for an API could be useful. In my experience,
however, it's usually more than just the view that changes
between versions. The controller receives customizations as
well, sometimes. Therefore, I think that versioning the views
is not a "majority case" and shouldn't be a core feature.
I think the best course of action here is to leave the
functionality as a gem and promote it as yet another
alternative to designing an API with Rails.
On 15/09/2012, at 19:18, Jim Jones <[email protected]> wrote:
My friend Ben Willis and I have developed a gem for the
versioning of Rails views.
https://github.com/bwillis/versioncake
The versioning is done by the naming convention. Image the
following series of files :
show.v3.json.jbuilder
show.v2.json.jbuilder
show.v1.json.jbuilder
create.v2.json.jbuilder
create.v1.json.jbuilder
The developer pre-defines all view versions in their config.
When a specific view version is specified (via a header or
request param) , if the version of that view exists, it is
rendered, otherwise, the request _degrades_ to the previous
version.
This makes it really handy for APIs/Jbuilder views. For
example, if you defined a new version for your API, e.g. v3,
yet all other actions remain the same, the degradation will
automatically select the appropriate backward compatible view
(v2 for the create view above).
The versioning functionality is passive meaning that if the
version file extensions aren't utilized, the end user
(especially beginners) will not know that the functionality
exists.
Our end goal is to merge and submit a pull request for Rails core.
Would love to hear everyone's thoughts.
Jim Jones
http://www.github.com/aantix
--
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/9POep66BvoMJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/Oyigk16rMzwJ.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Core" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:rubyonrails-core%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
