Best Practice recommendation for URL parsing.

[tuxpowered]

This isn't so much a bug as it is a question about the best ways to parse the URL with Flask-restless.

For example, in "normal" flask you can set a variable in the URI like <int:version> or multiple request arguments. &foo=bar&monkeys=scripting&tux=powered

But with Flask-Restless you do not get to parse the URL in this manner.

http://api.example.org/<int:version>/table?name=something&ref=someRef
http://api.example.org/<int:version>/table/<string:name>/somthingelse?name=something&ref=someRef

So in the above examples how would someone access the url parameters? and the int:version varibles?

The use case is an existing API that does something like this..

api.example.com/v2/messages/<to_number>/<from_number>/message
api.example.com/v2/message/<uniques_id>/<action-to-take>

The best way I can determine is maybe by using post/pre processors, but that can get pretty labor intensive.

The other way might be to write the app.route() as normal and then redirect to the api-restless manager, but that in many ways kind of defeats the purpose.

Thanks for your input Sofar loving it.

[jfinkels]

Hi @tuxpowered. I'm not totally sure I understand your issue. Are you saying that while the default Flask-Restless URLs look like this:

https://example.com/api/articles
https://example.com/api/articles/1
https://example.com/api/articles/1/comments

You want to allow some part of the URL prefix to vary, as in a URL parameter, like this

https://example.com/foo/articles
https://example.com/bar/articles
https://example.com/baz/articles

and you want Flask-Restless to receive that additional information (in this case, foo, bar, or baz, depending on the request) and be able to make some decisions using it?

Currently we don't support that, and I'm not sure if it could be easily done from within Flask-Restless. The purpose of Flask-Restless is to allow you (the user) to quickly create some basic URLs that reflect the underlying database objects. It is not intended to be endlessly flexible, so I probably won't pursue this enhancement. But if I am not understanding your issue, please add another comment here!