Path versioning?

[Nick Gorbikoff]

Hi

Trying to figure out if praxis supports path versioning instead of sending it in the X-Api-Version header? I have to use a javascript client framework that has trouble sending / reading headers. It was designed around an expectation that all this meta info is sent recieved in a meta section of payload , where json is like 

{
  data:{
    // some data
  },
  meta:{
    count: "200",
    page: "5" ,  
    // etc
  }
}

and versioning and request url is done  like so ( works via GET for show and POST is for create type actions)

http://api.example.com/v1/products.json?some_param[nested_param]=some_value

[Josep Blanquer]

Nick,

 path versioning is not implemented, but should be easy to add in the way that the version plugs into the system. I'd suggest to create an issue for it so see what is the interest from others. You might even wanna give a stab at implementing it if you want, and I'd be happy to help.

Also, I think that based on what you're saying above, you could probably provide the version through the query string. This:

/products.json?api_version=1.0 

is equivalent to:

/products.json  (passing header X-Api-Version: 1.0 )

Cheers,

Josep M.

--
You received this message because you are subscribed to the Google Groups "praxis-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to praxis-suppor...@googlegroups.com.
To post to this group, send email to praxis-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-support/2c0e5e88-4a92-4915-b212-5917845c28c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[nick gorbikoff]

Hi Josep

?api_version=1.0   - what I meant here is that's how I send query params, I wouldn't want to pass api_version as a param. Headers or path are much cleaner, I just can't use headers due to limitations of the client JS library.  Apperently that's more common than I thought, especially when dealing with legacy systems  and systems that are not ruby based.

--
--------------------------------------

Nick Gorbikoff
nick.go...@gmail.com

[Stephen Crosby]

It sounds like you could get pretty close to what you're looking for by laying some special handling on top of your praxis app. Here's one totally untested idea as a rack middleware: https://gist.github.com/stevecrozz/3e8bcb71faed41b36ca9

Something like this could likely also be done in your web server's configuration, although you may have something more complex in mind.

To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-support/CA%2Bf7udT0oNVn%2BzTyPpVm21P%2BN9E0CeyEFAhoepOMi11w13uMXg%40mail.gmail.com.

[nick gorbikoff]

Thanks. I commented on you gist.

I might be over thinking this, it could simply be achieved with simple routing?

      routing do

        prefix '/v1/products'

      end

And when the time comes to add a new v2

then that can be achieved by setting up a new module / class structure

module V1

  module ApiResources

    class Products

vs 

module V2

  module ApiResources

    class Products

Than version can be set manually since the routing would determine which path / version to use  and serve.

Just thinking outloud right now

You received this message because you are subscribed to a topic in the Google Groups "praxis-support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/praxis-support/j-4WW2ViGmk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to praxis-suppor...@googlegroups.com.

To post to this group, send email to praxis-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-support/CAEhUSes7UpJWSU8KVjXOFmMHERjzUaCdT5813jUbPWdfnW-%2BsA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[nick gorbikoff]

This might also work for a specific use case . We want to expose parts of our internal api to our vendors, and we want it done through path like so

http://api.example.com/elf_corp/products ( their products, formatted the way they want them)

http://api.example.com/hobbit_inc/orders ( orders of their products, formatted the way hobbits want them)

while our internal api is

http://api.example.com/v1/products

Where these vendors / clients get a very specific / limited view  of the resources. While we could use params, to modify product resource on the fly, the views these vendors need to get are so different, that we would end up with huge monolithic decorators / views that do if/else type switching

Anyways point is that it is sort of a version of the api, instead of having a alpahnumeric version, it has a string identifier 

While internally we will develop various apps, that might need various version fo api as we test and implement various systems, our vendors / clients - have only one endpoint of consumption and the way they consumed our data hasn't changed and if it does at no point they need to use 2 version of api ( well they might need a test / dev api to access & test changes, but in production that's not an issue)

[Josep Blanquer]

Nick,

 I had some time this morning to whip out a PR to enhance the API versioning piece (and add path support).

https://github.com/rightscale/praxis/tree/63-path_versioning

You might wanna give it a try and see what you think? I'll wait on your feedback and other reviews before merging anything to master (and/or updating our reference docs).

I've added some details in the changelog: https://github.com/rightscale/praxis/blob/63-path_versioning/CHANGELOG.md#next

Cheers,

Josep M.

To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-support/CA%2Bf7udSKjLMo0%3DJV7ZAZpLF7S8LTciATsRqo9MrppAZp_mtDgw%40mail.gmail.com.

[Nick Gorbikoff]

Looks good - replyed on github in detail

[Josep Blanquer]

All,

 The changes for better support of API versioning (including path) have made it to master. Here's the changelog piece:

• Refined and enhanced support for API versioning:
  • version DSL now can take a using option which specifies and array of the methods are allowed::header,:params,:path(new)
    • if not specified, it will default to using: [:header, :params] (so that the version can be passed to the header OR the params)
  • the new :path option will build the action routes by prefixing the version given a common pattern (i.e., "/v1.0/...")
    • The effects of path versioning will be visible through rake praxis:routes
    • the default api prefix pattern is ("/v(version)/") but can changed by either
      • overriding `Praxis::Request.path_version_prefix and return the appropriate string prefix (i.e., by default this returns "/v")
      • or overriding Praxis::Request.path_version_matcher and providing the fully custom matching regexp. This regexp must have a capture (named version) that would return matched version value.

 Reference docs have been updated too: http://praxis-framework.io/reference/resource-definitions/#version

Thank you for the feedback!

Josep M.

On Thu, Oct 23, 2014 at 2:27 PM, Nick Gorbikoff <nick.go...@gmail.com> wrote:

Looks good - replyed on github in detail

--

You received this message because you are subscribed to the Google Groups "praxis-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to praxis-suppor...@googlegroups.com.
To post to this group, send email to praxis-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-support/059dac75-fae3-46cb-a33e-ddebc1c86449%40googlegroups.com.

[Nick Gorbikoff]

Great - we'll test it

Sent from my iPhone