Flask API – Browsable Web APIs for Flask
flaskapi.org
flaskapi.org
Flask API also shares the same architecture as the core of Django REST framework, which I think just has a really nice separation of concerns.
Also the interface of `request.data` means is easy to transparently support both JSON and form requests, and the nice content negotiation on responses means it's easy to build services that power both an HTML front-end and an API from the same endpoints.
Right now Flask RESTful is more mature of course, but I've got high hopes for this, and it's been super fun to build so far.
How does a browsable API work when it may need certain HTTP headers, request signatures, etc?
[0] https://helloreverb.com/developers/swagger [1] https://github.com/rantav/flask-restful-swagger
For those unfamiliar with Django REST Framework, please go take a look. One of the few, perhaps the only, web framework to take all (or maybe almost all) of Fielding's ideas behind REST seriously. This is more than just theoretical -- once you've created a client application that takes full advantage of a HATEOAS API, you'll understand that it's much more than an annoying acronym.
All this would be amazing coupled with angularjs…
Edit Oh, and I join the question: what about flask-restful?
Authentication policies will use a similar style to the renderers and parsers (and all of REST framework). You'll be able to set them per-view with a decorator, or set them system-wide in the config. You'll also be able to support multiple authentication policies.
Too much complexity added to project. Going REST patch is problematic when you have to integrate with with server-render style lib or service. SEO is shit. Angular doc is worse.
Auth is base on tokens, no sessions. I reused the ideas from here https://github.com/mrgamer/angular-login-example
def auth_required(f): @wraps(f) def wrapper(args, *kwargs): token = request.headers.get("X-Token") if token is None: abort(400) user = User.verify_auth_token(token, app.config["SECRET_KEY"])
If you don't make very heavy SPA like photoshop, don't use angular.
[1] http://blog.miguelgrinberg.com/post/restful-authentication-w...
1. Bare Flask 2. Flask RESTful 3. Flask Restless
I've spent quite some time investigating 2nd and 3rd options. Problems with 2nd:
a) Didn't bring much to the table comparing to pure Flask. Extra abstraction and complexity that without much improvements b) Swallowing Flask exceptions c) Risk that the project will be abandoned and poor maintenance (commit frequency)
3rd: Direct mapping to SQL-Alchemy models is too restrict. Hard to change stuff - very opinionated
I end up with pure Flask. It's already good with enough rest framework!. Great balance between power and abstraction.
I'm looking forward to dig into this project. Would be great if it has great integration with flask admin and security. Also support for OAuth flows would be awesome.
I have a few question for the author - of top of my head. How do you handle pagination? one example returns json array, what about JSON vulnerability?
I've been wanting to do something like this for a certain time, so I have a few questions if you don't mind.
How do you handle authentication? Tokens? Cookies? Is there a special "API key" for your web app?
And if there is, what's the point? Would the only reason to ever change that key be to force old clients to upgrade if the API changes?
Side point: I don't have a reference for this, but from what I understand the JSON array vulnerability has long since been closed in all sane browsers.
I'm building an AngularJS + REST server using Eve for the server. It has saved me so much time that I'm putting my dev effort mainly into a comprehensive test suite because there's so little dev work to do (btw - I'm not the author, it's just the fastest framework I've found for developing REST APIs - and I've tried Django REST framework & tastypie).
wondering how Eve stacks up to that. Sandman you just connect it to the DB and it's supposed to give you a REST api
When I need a REST-ful API for a Flask app, I just build the routes needed and code it up myself. Why both adding a whole extra framework for something? Flask by itself is already capable of supporting REST-style requests, so what does this do again? How much of the example listed was ordinary Flask-webapp code and how much was this extension? Add an HTML view to a JSON object and form for making REST requests?
Between this and the User extension from last night, I must be missing something. Or maybe I'm just old.
I am considering factoring the core of both Flask API and Django REST framework out into a library that could be integrated with any Python web framework - But that's not going to happen right away, so probably not much use to you in the immediate future.
Flask API is pretty simple tho - so there might be bits you can borrow from - perhaps the content negotiation implementation, browsable API implementation, or some of the general API style/separation of concerns that Flask API and Django REST framework both share.
The big win would be having more than one project sharing the same APIs for renderers, parsers, authentication, permissions and throttling policies - that way there'd be scope for writing at least some libraries that work cross-framework.
Framework agnostic libraries is one of the reasons Haskell has had me smitten for quite a while now
Keep it up OP, I'm interested to see how this progresses and I'll be following on github.
[1] flask-login and flask-principal come to mind, though they still require a writing a lot of code (especially flask-principal).
So great, what is Flask? What is this about?
Flask is a web framework for Python. It's smaller and lighter than Django, and can be picked up very quickly. Basically, the author of this library has a well-liked REST framework for Django, and folks are excitedg to see this goodness being brought over for Flask.
Any dates for 1.0 release? I'm looking forward to the authentication and such.
What would be great is also some implementation of Sandman's auto inspection of database to create REST api, with support for One to Many, Many to Many relationships.
Great job!
If anyone wants to give me a coupla days paid work on this, then yah I'm sure that could be arranged. :)