FAQ
Over in this thread<http://www.mail-archive.com/catalyst@lists.scsys.co.uk/msg14226.html>
was
a discussion on API versioning and implementing via Accept: headers vs.
adding a version in the URL. Looks like using a version in the URL is
winning.


We have existing chained actions that might look like this:


/account/<id>/widget/<id>




If want to migrate to a new version scheme in the URL like this:


/api/v1/account/<id>/widget/<id>




This would be the same action chain as the first path -- and both would
work at the same time.


Is there any way to support both actions via Chained dispatching? Or will
I need a role that looks for that pattern and strips it of the request
during prepare_action?


I've done something similar in the past where I added a language tag at the
start of every path:


/en_us/some/path/1234




I strip that off and then update $c->req->path for dispatching.






Again, I'm in the Accept: header camp for versioning, but I'm finding more
and more discussion on using URLs. There's an e-book
<http://pages.apigee.com/web-api-design-ebook.html>that seems to be cited
often. I'd be interested in other's view on that book -- it seems written
from a practical Rails programmer point of view instead of a REST purist
view. There's a lot in that e-book I don't really agree with (plural
nouns?), but the practical usage seems to be winning out. Hope it's not a
mistake in the long run.




--

Bill Moseley
moseley@hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20131015/a6bd44a2/attachment.htm

Search Discussions

  • John Napiorkowski at Oct 21, 2013 at 4:08 pm
    I'd probably myself want some plack middleware that would convert


    /api/v1/account/<id>/widget/<id>




    to?




    /account/<id>/widget/<id> ? ?with accept type application/mycompany.v1+json


    But you could probably support changing the URL path pretty easily with either setting the controller namespace to have v1 in it, or adding a root tot he change that specifies the new extra path part.


    I understand the development word seems to prefer making version part of the path. ?depending on your logic and the type of changes introduced it may or may not be easier to take one approach or the other.


    john




    On Tuesday, October 15, 2013 1:01 PM, Bill Moseley wrote:


    Over in this thread?was a discussion on API versioning and implementing via Accept: headers vs. adding a version in the URL. ? Looks like using a version in the URL is winning.


    We have existing chained actions that might look like this:


    /account/<id>/widget/<id>


    If want to migrate to a new version scheme in the URL like this:


    /api/v1/account/<id>/widget/<id>


    This would be the same action chain as the first path -- and both would work at the same time.


    Is there any way to support both actions via Chained dispatching? ? Or will I need a role that looks for that pattern and strips it of the request during prepare_action?


    I've done something similar in the past where I added a language tag at the start of every path:


    /en_us/some/path/1234


    I strip that off and then update $c->req->path for dispatching.








    Again, I'm in the Accept: header camp for versioning, but I'm finding more and more discussion on using URLs. ? ?There's an e-book that seems to be cited often. I'd be interested in other's view on that book -- it seems written from a practical Rails programmer point of view instead of a REST purist view. ? There's a lot in that e-book I don't really agree with (plural nouns?), but the practical usage seems to be winning out. ?Hope it's not a mistake in the long run.




    --
    Bill Moseley
    moseley@hank.org
    _______________________________________________
    List: catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Bill Moseley at Oct 22, 2013 at 4:09 pm

    On Mon, Oct 21, 2013 at 9:08 AM, John Napiorkowski wrote:


    I'd probably myself want some plack middleware that would convert

    /api/v1/account/<id>/widget/<id>


    to


    /account/<id>/widget/<id> with accept type application/mycompany.v1+json

    I guess that would separate that out of the app.


    I'm currently using this approach in an app role:


         my @path_seg = split '/', $c->req->path, -1;
         my $base_uri = $c->req->base;


         return unless @path_seg && $path_seg[0] =~ /$path_prefix_version_regex/;


         my $match = $1;


         die "path_prefix_version_regex ($path_prefix_version_regex) matched but
    failed to capture any value"
             unless defined $match;


         $c->stash->{path_prefix_version} = $match;
         $base_uri->path( $base_uri->path . shift( @path_seg ) . '/' );


         # Force $req->path to reload _path next time $req->path is called.
         $c->req->_clear_path;







    But you could probably support changing the URL path pretty easily with
    either setting the controller namespace to have v1 in it, or adding a root
    tot he change that specifies the new extra path part.

    But would that support it being an optional prefix? Need both to work at
    the same time.







    I understand the development word seems to prefer making version part of
    the path. depending on your logic and the type of changes introduced it
    may or may not be easier to take one approach or the other.

    It does seem like that. Deciding to go with the flow vs. doing it the
    "right" way is the decision to be made. I like your suggestion to map it
    to an Accept header -- best of both worlds.




    --

    Bill Moseley
    moseley@hank.org
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20131022/331d2462/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedOct 15, '13 at 6:00p
activeOct 22, '13 at 4:09p
posts3
users2
websitecatalystframework.org
irc#catalyst

2 users in discussion

Bill Moseley: 2 posts John Napiorkowski: 1 post

People

Translate

site design / logo © 2021 Grokbase