I suggest you ...

Support path parameters

Please support path parameters and let the users choose what values to test with.

37 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Johnny LuuJohnny Luu shared this idea  ·   ·  Admin →

    17 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Huiming TeoHuiming Teo commented  · 

        Hi Lukai,

        When I define the URL as:

        ## Message headers [/messages{?sort_by}]

        The generated "Show code sample" or "Try It" code looks like this:

        curl --include \
        "http://foo.apiary.io/messages{?sort_by}"

        which obviously incorrect, the URI template should be expanded to a valid URL.

      • Lukas LinhartAdminLukas Linhart (Admin, apiary.io) commented  · 

        Hello,

        RFC is mostly implemented. Please test it and let us know how they fulfill your use cases and please report any bugs or missing features you feel are necessary for you.

        Templates are still opt-in (just go to settings), but we will probably enable them for everyone in a few weeks.

        From your responses, I feel there are related issues You'd like to see in apiary. I have created separate ideas from them, please vote for them to help us prioritize:

        http://apiary.uservoice.com/forums/120125-general/suggestions/3096648-test-server-from-blueprint
        http://apiary.uservoice.com/forums/120125-general/suggestions/3096640-add-a-way-to-specify-default-parameters-for-uri-te

        Thanks again for your feedback and stay in touch!

        Lukas

      • Jakub NesetrilAdminJakub Nesetril (CEO, apiary.io) commented  · 

        @Andrei - we're wrestling with the RFC, too… providing default values for the parameters isn't really covered in 6570 - any ideas/wishlist what you would feel is more appropriate?

      • Andrei NeculauAndrei Neculau commented  · 

        Can the docs be updated a bit, at least to hint at this possibility, even as WIP?
        I didn't see the comments below, and just deleted a comment voting for "If you will have only the latter specified, it will be matched even if called without parameters. If both, then the resource with most-matching variables will be matched."

        Anyways, good work, Apiary!
        though I'm not a fan of URI templates :) but query params can be a nice feature

      • Lukas LinhartAdminLukas Linhart (Admin, apiary.io) commented  · 

        Good morning everyone,

        partial support for querystrings has now been added.

        You can now have resources like those:

        /invoice/{id}

        /invoice/{id}{?year}

        If you will have only the latter specified, it will be matched even if called without parameters. If both, then the resource with most-matching variables will be matched.

        Multiple variables are supported

        /invoice/{id}{?year,month,day}

        (matches METHOD /invoice/123?day=12&month=12)

        It still stands that non-templated versions inside path are preferred over templated ones, so this

        /invoice/123

        is preferred over this

        /invoice/{id}

        when METHOD /invoice/123 is called.

        This should allow you both to handle special-cases and to hack around our nonexistent support for multiple responses from a single resource.

        All other features from level 2 and 3 (#.* expansion etc.) are not yet thoroughly tested and would probably result in non-matches, undefined behavior and dead kittens.

        That, of course, should not stop you from trying and from reporting bugs.

        Also, please let us know if that satisfies your use-case and what is most important for you now (= what should we implement first).

        Ability to specify values for examples (or tests, in the future)?
        More expansion modifiers?
        Ampersand-separated query strings?

        Please comment.

        Have a nice day,

        Lukas

        P.S.: Again, for this to work, please enable URI templates in beta area in settings.

      • AnonymousAnonymous commented  · 

        That's awesome! I'm really needing level 1 for query params at the moment, but this is just super! I'll give the path params a run while I'm waiting for query params. Very interested to see how you've settled on specifying variable values and responses for testing.

      • ApiaryAdminApiary (Admin, apiary.io) commented  · 

        Hello everyone,

        we have finally settled other things and this one is in our focus right now.

        Level 1 support is now live (meaning you can specify your resources in /very/resource/{templated}/{way} and they are matched in inspector accordingly).

        This feature is considered beta and is thus opt-in -- it may be enabled in settings.

        More broad support (especially {?query string params}) is coming soon, we'll keep you posted.

        If you are interested, please test it and let us know here about any problems.

        Thanks,

        Lukas

      • ApiaryAdminApiary (Admin, apiary.io) commented  · 

        Hi,

        well, we are testing beta with level1 support (path parameters, not query parameters), but those are on their way.

        ETA is few weeks at most, we'll keep you posted.

        Thanks for the interest,

        Lukas

      • AnonymousAnonymous commented  · 

        +1 on the need for query parameter support. We need path parameter support too, but it's lower priority atm. If my read of RFC 6570 is correct, it can be used for query parameters too. The third example in section 1.1 shows a template for it (http://example.com/search{?q,lang}) though I haven't yet found an illustration of the specification of values. Still reading. You got an ETA ? I need it yesterday ;-)

      • umbraeumbrae commented  · 

        Seems reasonable to me. It also speaks to query parameters which is what I came here to suggest support for. It'd still be unclear how we're supposed to document query parameters, though.

      • ApiaryAdminApiary (Admin, apiary.io) commented  · 

        We are actually using express.js ;), but we are probably going to prefer standard URL templates as per RFC 6570.

      • ApiaryAdminApiary (Admin, apiary.io) commented  · 

        Hello,

        thanks for the feedback. We are now working on One Marketing Thing and this will be our number one priority immediately after that.

        Lukas

      Feedback and Knowledge Base