I love writing RESTful services in Flask, but I'm thinking about switching to Django solely because of Django Rest Framework, which seems to be the closest of all Python REST projects to Fielding's original idea, or what is now being called HATEOAS. It's also extraordinarily well-documented and designed.
Has anyone here used SQLAlchemy with Django Rest Framework? I know it's possible to use SQLAlchemy with Django, but I'm curious if this will cause any issues with Django Rest Framework. I probably won't switch if I can't use SQLAlchemy.
You probably wouldn't be able to use ModelResources (the ones that get fields automatically from the Model, similar to ModelForms) but apart from that I don't see anything that ties Django Rest Framework to Django's ORM
A lot of things depend on Django's ORM, admin and REST libraries being the most useful.
I once tried to use SQLAlchemy to write some particularly complex queries and used aldjemy[0] for that. While it worked reasonably well for a few queries, it made things a bit confusing by having two ways of querying. It was also annoying to debug things at first (since I was using SQLAlchemy's own executor), so I ended up generating SQL and explicitly feeding that into Django's executor.
It's generally a pain to use SQLAlchemy with Django. It's the primary reason I avoid Django.
@almost is right - there's nothing that strictly ties you in to Django's ORM.
A few thoughts:
* You'll need to use the Serializer class rather than the automatic ModelSerializer.
* You'll need to do a bit of tweaking if you want to use the Generic class based views (since they default to using the standard Django querysets), but if you're just writing the views yourself there's nothing tying you to the ORM.
I was initially a bit worried about adopting Django REST Framework due to it being the new kid on the block, but tomchristie's dedication to the project has really put me at ease. Adding the deprecation policy is great for long term stability. He's making all the right moves to build a lasting ecosystem of contributors and setting a collaborative tone on the project.
So does this use cookie based authentication? Isn't there a more preferred way to do authentication in REST? (I'm actually trying to figure this out now)
It supports cookie auth for the browse-able web interface it makes available for APIs. It's optional though and it also supports HTTP auth and other auth styles as well I think.
It supports various types of authentication, including Django's standard session-based auth (which is useful if you're building AJAX clients to your Web API)
I'm currently using tastypie, but will consider Django REST Framework in the future, based purely on the fact that this is a new release and has a deprecation policy. tastypie is still only a pre-1.0 beta. A better evaluation is certainly needed though.
I played with Django REST framework a week ago and was surprised on how easy it was to get going with it.
The documentation is almost complete and the tutorial is especially nicely done as it begins with a naive - and tedious - approach and then proceeds to simplify everything using the advanced features of the framework. This really helps prevent the 'magic' effect as we get a clear understanding of what is happening behind the cover and where one should look to extend or override the default behavior.
Overall, I found it to be quite feature-rich. One aera of improvement might be the built-in token-based authentication. It seems that it's currently using a "shared secret" approach instead of supporting signed-requests, thus limiting its use to HTTPS only.
17 comments
[ 3.8 ms ] story [ 42.3 ms ] threadHas anyone here used SQLAlchemy with Django Rest Framework? I know it's possible to use SQLAlchemy with Django, but I'm curious if this will cause any issues with Django Rest Framework. I probably won't switch if I can't use SQLAlchemy.
I once tried to use SQLAlchemy to write some particularly complex queries and used aldjemy[0] for that. While it worked reasonably well for a few queries, it made things a bit confusing by having two ways of querying. It was also annoying to debug things at first (since I was using SQLAlchemy's own executor), so I ended up generating SQL and explicitly feeding that into Django's executor.
It's generally a pain to use SQLAlchemy with Django. It's the primary reason I avoid Django.
0. https://github.com/Deepwalker/aldjemy/
A few thoughts:
* You'll need to use the Serializer class rather than the automatic ModelSerializer.
* You'll need to do a bit of tweaking if you want to use the Generic class based views (since they default to using the standard Django querysets), but if you're just writing the views yourself there's nothing tying you to the ORM.
* You'll need to deal with the transaction management, probably by using middleware something like this: http://stackoverflow.com/questions/6606725/best-way-to-integ...
If it is something you pursue it'd be tremendously helpful if you could post to the list on how you get on.
So yeah, thanks Tom!
I'm currently using tastypie, but will consider Django REST Framework in the future, based purely on the fact that this is a new release and has a deprecation policy. tastypie is still only a pre-1.0 beta. A better evaluation is certainly needed though.
Overall, I found it to be quite feature-rich. One aera of improvement might be the built-in token-based authentication. It seems that it's currently using a "shared secret" approach instead of supporting signed-requests, thus limiting its use to HTTPS only.
Yeah, I believe oauth1 support would address that, and is planned. :)