non-query string parameters

[kmayoral]

Hi guys, I like the support for placement of parameters within the URI but before the query string, like so: "/api/test/get/:param1". Thanks for that as well!

The only issue I find with this is that if :param1 is defined as an optional parameter then the resulting URI will still contain the text ":param1" when the value for :param1 is empty. If :param1 is set to a value before the request is made, the URI is updated correctly to send that value; it's only when empty that the expected behavior or ":param1" being removed from the URI doesn't happen.

[kmiyashiro]

@kmayoral: Can you give me an example of that? Like say,

http://api.acme.com/:required/:optional and if :optional is blank, it sends http://api.acme.com/bob/:optional? Would it make more sense to treat the optional param as another resource/method?

Example:

http://api.acme.com/:resource - Return all from resource
http://api.acme.com/:resource/:specific - Return a specific item from resource

http://api.acme.com/users - All users
http://api.acme.com/users/bob - Just bob

[kmayoral]

kmiyashiro - yup your example is exactly what I was bringing up. You're right that creating another resource/method could solve the problem easily, but I guess it'd be more of a convenience to have both cases be handled by the same resource/method if they relate to the same type of request.

I guess as an example, if there was a method to retrieve a paginated list of items from a gallery of sorts, you could optionally specify :optional_start_page to state the page you want to start retrieving items from, but if left unspecified, it would default to returned the first page.
http://api.acme.com/gallery/:optional_start_page

These cases could be split into two different resource/method entries in the system, but it would just be convenient to be handle them in one case to avoid duplication in the API view page.

That being said, you did bring up a working alternative approach for my original issue (creating another method), so if this request isn't implemented, it won't hurt the functionality of the system.

Thanks for hearing me out though!

[kmiyashiro]

Yeah, shouldn't be too hard to add. I also noticed we don't have client-side validation for required fields which is kind of related.

[gggeek]

It would be nice to get more docs about support for non-query-string parameters (in README.md).
Right now there is no example of such possibility, which makes the casual user think it is not supported

[smgilson]

I have the same issue as originally posted, I want to be able to generate a URI in the from: "/api/test/get/:param1"

But, I can't tell from this thread if it has been made possible and, if so, how to do it.

Thanks

[catapultsoftworks]

I'd also like to be able to make restful parameters optional without resorting to another resource. I should be able to do /pets and /pets/123 in the same resource definition. Is there a way to do this?