We Keep Coding

Flask filter by url

I'm using Flask-Restless and Flask-SQLAlchemy on my application. I can't remember when, but I did a example that I'm almost 100% it was with Flask-Restless to filter a query in the url like /example?id=1. Although the pagination plugin is ok, I can't replicate the filtering by attribute on the url.
I've been searching like crazy on how to do that again but I can't find it. I'd appreciate if someone here has a way of doing that.
PS.: With Flask-Restless, how do I make a GET request on a endpoint passing a parameter like GET /example {"id": 1}?
PS2.: I know that if I put the id after the "/" I'll get the object, but I want to filter any field I want.

Dynamically add URL rules to Flask app

I am writing an app in which users will be able to store information that they can specify a REST interface for. IE, store a list of products at /<username>/rest/products. Since the URLs are obviously not known before hand, I was trying to think of the best way to implement dynamic URL creation in Flask. The first way I thought of would be to write a catch-all rule, and route the URL from there. But then I am basically duplicating URL routing capabilities when Flask already has them built-in. So, I was wondering if it would be a bad idea to use .add_url_rule() (docs here, scroll down a bit) to attach them directly to the app. Is there a specific reason this shouldn't be done?

Every time you execute add_url_rule() the internal routing remaps the URL map. This is neither threadsafe nor fast. I right now don't understand why you need user specific URL rules to be honest. It kinda sounds like you actually want user specific applications mounted?
Maybe this is helpful: http://flask.pocoo.org/docs/patterns/appdispatch/

I have had similar requirement for my application where each endpoint /<SOMEID>/rest/other for given SOMEID should be bounded to a different function. One way to achieve this is keeping a lookup dictionary where values are the function that handle the specific SOMEID. For example take a look at this snippet:
func_look_up_dict = {...}
#app.route('<SOMEID>/rest/other', methods=['GET'])
def multiple_func_router_endpoint(SOMEID):
if SOMEID in func_look_up_dict.keys():
return jsonify({'result' = func_look_up_dict[SOMEID]()}), 200
else:
return jsonify({'result'='unknown', 'reason'='invalid id in url'}), 404
so for this care you don't really need to "dynamically" add url rules, but rather use a url rule with parameter and handle the various cases withing a single function. Another thing to consider is to really think about the use case of such URL endpoint. If <username> is a parameter that needs to be passed in, why not to use a url rule such as /rest/product/<username> or pass it in as an argument in the GET request?
Hope that helps.

Distinguishing between GET and POST data in CherryPy?

I've been deciding between Python web frameworks for a project of mine and I've really liked how lightweight, flexible, and concise CherryPy is compared to others. The only problem I'm having is I can't find any documentation on how to distinguish between data sent via GET and via POST.
For example, I don't want users to be able to provide their login credentials through a GET request (http://example.com/login?username=user&password=pass) but, according to CherryPy's tutorial, all data is sent as method parameters, no matter what HTTP method they're sent as. Is there some way to say I only want the POST data or do I have to use MethodDispatcher?
Thanks!

See the docs.
A string containing the HTTP method, such as "GET" or "POST". Set
in the "run" phase.
looks like checking cherrypy.request.method is what you want to do.

Best way to request-scope data in Django?

I'm wondering if there's a clever pattern for request-scoping arbitrary information without resorting to either TLS or putting the information in the session.
Really, this would be for contextual attributes that I'd like to not look up more than once in a request path, but which are tied to a request invocation and there's no good reason to let them thresh around in the session.
Something like a dict that's pinned to the request where I can shove things or lazy load them. I could write a wrapper for request and swap it out in a middleware, but I figured I'd check to see what best-practice might be here?

Just assign the dictionary directly to the request. You can do that in middleware or in your view, as you like.

Context processors. They are called once for every request and receive the actual request object - so you can add ANY data to the context, also based on the curent request!

Is www.example.com/post/21/edit a RESTful URI? I think I know the answer, but have another question

I'm almost afraid to post this question, there has to be an obvious answer I've overlooked, but here I go:
Context: I am creating a blog for educational purposes (want to learn python and web.py). I've decided that my blog have posts, so I've created a Post class. I've also decided that posts can be created, read, updated, or deleted (so CRUD). So in my Post class, I've created methods that respond to POST, GET, PUT, and DELETE HTTP methods). So far so good.
The current problem I'm having is a conceptual one, I know that sending a PUT HTTP message (with an edited Post) to, e.g., /post/52 should update post with id 52 with the body contents of the HTTP message.
What I do not know is how to conceptually correctly serve the (HTML) edit page.
Will doing it like this: /post/52/edit violate the idea of URI, as 'edit' is not a resource, but an action?
On the other side though, could it be considered a resource since all that URI will respond to is a GET method, that will only return an HTML page?
So my ultimate question is this: How do I serve an HTML page intended for user editing in a RESTful manner?

Another RESTful approach is to use the query string for modifiers: /post/52?edit=1
Also, don't get too hung up on the purity of the REST model. If your app doesn't fit neatly into the model, break the rules.

There is no such thing as a RESTful URI. It is false concept as URIs should be completely opaque to the client.
If it helps you to properly implement the HTTP uniform interface by avoiding verbs in your URIs then that's great, but don't feel constrained by what your URI looks like. It is very limiting to think of resource modeling as type of data modelling. A RESTful system usually needs to do way more than just CRUD operations, so you need to be creative about what resources you make available in your system.
If you create a URL and dereferencing it returns a 200 status code, then that URL refers to a resource. If you create another URL and it also returns a 200, then that is a difference resource.
That means:
http://example.org/customer/10.xml
http://example.org/customer/10.json
http://example.org/customer/10?format=xml
http://example.org/customer/10?format=json
are 4 different resources, and
http://example.org/customers
http://example.org/customers?closed=true
http://example.org/customers?page=2&pagelength=20
are also different resources.
Therefore to answer your question, if you do
GET /post/52/edit
and it returns a 200 status code and a representation, then it must be a resource.

Instead of calling it /post/52/edit, what if you called it /post/52/editor?
Now it is a resource. Dilemma averted.

I don't think /object/id/action is part of the REST specification.
Is your editor going to be a generic thing for all objects ? Then maybe your URL should look like
/editor/object/id
The action is an HTTP Verb ( GET,PUT,DELETE,POST ) and is supposed to be a part of the HTTP request and not part of the URL. For a better summary, check out this Wikipedia article on RESTful_web_services.