Super useful tool, thanks to Tom and everybody who contributes. When we began moving some of our APIs from Django to Flask at my company, djangorestframework was the single tool/package that I missed most. It's lovely.
What are the plans (if any) for continued development on Flask-API?
I'm curious why you decided to move APIs from Django to Flask? We've built our APIs on Flask, and, though I like Flask a lot, the major complaint is that there's no real story around user authentication and authorization, endpoint versioning, and a handful of other things that aren't directly serving the purpose of the API, but are important nonetheless.
There are a hodge-podge of plugins to do various things, but they don't necessarily share the same design principles or work well together. Some are so abstracted that by the time you've got a concrete implementation you could have just rolled your own.
I am writing an API right now in Flask, and I chose it over Django never having used Django for a REST service before.
When you say "there's no story" around auth, endpoint versioning, and other things does that just mean that you're not forced to follow those conventions with Flask / that Django offers utilities to help? I am a bit confused/curious what you meant by that since I've seen some wonderful Flask auth work, and endpoint versioning is pretty standard on most APIs, but seems like Django is a bit more strict with what they want you to do.
strict in what way? I've built many api's using django-rest-framework and it is truly awesome to work with, completely extensible and flexible and never seems to get in my way
At the moment it's on hold - I certainly won't be doing anything with Flask until the Kickstarter work is all complete. I'm undecided after that.
It'd be interesting to get your opinion on what your take would be on using Django/Django REST framework if it had decent built-in support for use with SQLAlchemy.
EDIT this conversation came up while I was writing this comment on another thread. Some of my questions have already been answered so I've reworded it.
Said it before, and I'll say it again - DRF is one of the few things that makes me wish I was on Django.
Is the newer DRF code abstracted nicely to make a port to Flask easier?
It's something I actually looked at doing myself a year ago but there looked to be a lot of effort involved.
I often look at projects that are Django-this or Flask-that and think to myself - this could be a nice clean agnostic library with layers for which ever framework. Often by that stage it's too late, everything is too embedded.
In this case, I guess that DRF intrinsically deals with the framework specific layers a lot so it's probably necessarily tightly bound.
Well actually no, it'd be very feasible to re-write Django REST framework as a framework agnostic core. I've done a bit of exploratory work with this and there's nothing there that I think would be particularly fiddly.
The main questions would be how we'd manage support, packaging, documentation etc. Also is the benefit worth it if it means an extra level of indirection for our existing user-base? Right now focusing on Django REST framework in it's current form feels like the best effort-reward, but there's no fundamental architectural reasons stopping us from moving to a more decoupled core, with a Django specific integration layer on top of that.
Interesting. Thanks for the info. Definitely understand not wanting to muddy the waters. Especially at this stage, the new Django version obviously has to be the focus.
That said, if the core was sufficiently decoupled that you could split it out, that would be a major win for the Flask guys. pip install djangorestframework could work just as it does (by installing drf_core). The Flask community could then create flaskrestframework which also installs the core and uses that. I guess the djangorestframework project could even contain everything, so long as the core module didn't depend on django.
Then the Flask guys could maintain a wrapper and some lightweight Flask specific documentation with references back to the main docs.
As I say, it would be silly to do it now, but if it turned out to be easy to do in the long run, it wouldn't have to impact on the work you're doing too much.
As ever, even though I'm not even using the project, thanks for the work. I spent a long time reading through your code a couple of years back. It was really enlightening and I learnt a lot. Thanks again.
I'm personally working with a lot of hand-rolled SQL/stored procedures but I know there are people within the organization using SQLAlchemy's schema reflection to work with the legacy tables. Being able to use something like Django Rest Framework to build an API on top of that would be nice indeed.
We use both. I came in with a preference for Django but the applications we build are generally talking to legacy data stores so we more or less lose the Django ORM right off the bat. That cancels out a lot of the advantages Django has, unfortunately.
We use Django for legacy databases, both as a readonly way to access data in a managed data warehouse and to replace an application that had not the nicest schema to begin with. Routers to the rescue.
Of course if the database you're working with is a shambles, then you're going to have a bad time.
DRF brought me back to Django after a foray into Flask-land. It's a pleasure to work with. Thanks for your work, and to the backers who funded the latest development!
Reason I ask is due to how django keeps (IMO) gaining territory on the corporate and/or business stack. I get requests for support and new development consistently from companies in different markets/regions.
Broadly, we aiming for it to be a mature, sustainable and well-supported general purpose Web API framework.
We tend to be fairly aggressive about keeping the scope manageable in order to keep to that. For example 3.1 moves some functionality out into third party packages, so that we can concentrate on the quality of the core framework.
Agreed, although I wish there was more documentation on the benefits of each feature, rather than just how to implement it.
E.g. there are dozens of pages on how to implement serializers, which is great, but the section on the benefits of serializers is only a paragraph or two long. So after reading all the documentation I'm still unclear as to the best practices on when vs when not to use them, and what the best practices are for endpoints that don't take advantage of them. I'm sure this kind of stuff is obvious to people who have been using it for a while, but after just going through the tutorial and then reading the relevant API pages I was still unclear on a bunch of issues.
Perhaps, but it's definitely wrong in places. I was working with a project this afternoon and the examples given didn't actually work. I should definitely take some notes on which bits were wrong, as it would be useful to have them fixed.
I've been using tastypie for the past few months in a project and I'm kindof regretting it - I'm finding some of the design decisions hard to understand and not super well documented. But I've gotten to the point where I'm using it in production and it feels like it might be too big of a pain to switch at this point.
I'm not an expert, but from what I've read of the docs of both projects I understanding DRF is more modular and easier to customize with its Serializer, Parser, View, Viewset, etc. classes than Tastypie with its monolithic Resource class.
I've got a little experience with both. I went full bore into DRF, and found myself wrestling with the framework too much. I wanted to use the framework (ModelSerializer), but found it difficult to find the hooks to customize some behavior. Then going down a layer of abstraction felt like I had to do too much. This is probably the reality of any framework, not necessarily the fault of DRF.
Right now I'm using django-restless. I'm sticking with it for now. It uses Django forms for validation, which works ok even though they weren't meant for validating json input. Now I'm wondering if it would be best to just use Django, and be restless in style. Perhaps DRF, restless or some other libraries would have some pieces that I could use in a more library fashion if I wanted them.
I've started using DRF last week and I don't know why I did'nt use it before.
The authentication framework and the Model serializer are really good points to start, but I was missing some versioning scheme and 1 week later here it comes. Great work, Tom.
Of course you can use many to many fields with ModelSerializer.
I'm not sure what you mean here, but I'd suggest opening an issue if you believe there's a problem - we're pretty comprehensive about dealing with incoming issues.
An issue that I've consistently run into is being able to write to related models. I can serialize them just fine, but without being able to write, it forces users to come up with nasty work arounds. To be fair, I hate having to write resources that handle writing nested objects, but there are some many front end use cases where multiple writes is not ideal.
Oh right, writable nested serializations, sure. I won't rehash the reasons that we don't support that in core (ill defined what behavior the user should expect) but yeah it'd still be good to have a third party package that does a decent "best effort" job of that.
My personal take on this is forget about "shitty hacks" or trying to handle this automatically, and just write the serializer create and update methods explicitly.
I know why it's not supported and I agree that there should be a third party package for it that is more or less officially supported/recommended like the jwt package.
Most recently I created a new handler object that runs some introspection of the model. I then override my model view sets' create and update methods to implement the handler. Maybe I should get off my ass and open source it (currently buried in a project).
What are the plans (if any) for continued development on Flask-API?