I'm involved in the Django rest framework based project.
Django and DRF are fantastic - I heavily cover complicated parts of my code with unit tests, using built-in DRF and Django testing tools.
We also have a QA team in my project. The team is using pytest to test the developed API. QAs don't know Django or DRF. They just treat the API as a balckbox and don't rely on any Django tools.
I looked at their code once and saw how much work is being done on their side. Most of the time they test not my code, but rather they test Django functionality.
We have CRUD for complicated models. It's so easy for me to create CRUD with DRF, since I have most of the tools bult-in, while testers create models for various requests and responses and it's really complicated on their side. When it comes to authentication, they have fancy fixtures, while i use 'force_authenticate'... In the end their code looks more complicated than mine.
My question: is it really helpful to test DRF API externally, provided it's already covered with many unittests?
Related
I'm using Django with DRF as just an API--it doesn't serve any FE assets of any kind. I know the Django testing suite is built on the Python native unittest library and plan on using it for unit testing.
When it comes to integration testing, is it sufficient or should something like Behave be used?
If unittest is sufficient, should it be used in conjunction with some kind of faker?
If you want to test the API contract, you need:
to read the relevant documentation
have a way to generate models you need. My advice is to use factory-boy.
This setup will test your urlconfs, views, serializers and to some extent your models, without the need for real server and without the need to mock API responses.
I'm used to test Django Rest Framework apps with the test tools available directly in Django and DRF. It's possible to setup a dummy client and expose all the REST methods.
At the same time, I see many posts talking about Postman for API testing. I fail to see where the advantage would be.
Is there any reason for me, a single developer, to use Postman? Or perhaps there is only an advantage for shared projects?
I have been using Flask for Building REST API on the development level. I want to create REST API at Production Level. So which Python web framework would be Best?
These frameworks I saw while searching:
CherryPy
Flask
Django
Pyramid
TurboGears
Pylons
Web2py
Falcon
Bottle
Etc.
Django has a big support for REST API. According to my own experience I'd advice Django.
See more here: https://www.django-rest-framework.org/
For a REST API, I would use FastAPI. It has a strong reputation.
I have used it for several projects, and I like it because it fairly easily lets you do the right thing without much work. For instance, it relies upon pedantic to ensure the proper data types for what you are sending/receiving.
I am starting with developing REST API's with the Djano framework. Previously I have worked extensively with Java related frameworks specifically with SpringBoot.
If I take an example of a REST API in Java based framework below is the directory structure that I have mostly used :
So something mostly on the lines of a MVC Design Pattern.
Also in java mostly each class is written on a new file, however the tutorials that I have been looking around writes multiple classes within one file, is this the best practice around Django?
Also I see that in Django we create a project and then inside it we create an app. Are these app equivalent of package in java?
Also, in SpringBoot and other java related frameworks we normally follow a Top-Down approach, where a Controller recieves a call which is further passed on to the Service where all business logic resides which then further calls DAO(Repository) for CRUD and the corresponding result is passed from DAO to Service back to Controller which generates the formatted response.
What I have moslty seen in Django is all the logic is written on views which calls Model for CRUD. Don't we follow SOLID priciples here?
If I take an example of a library management system, How will one design that around the Django framework?
This is a great question, but I'm not sure that StackOverflow is the right place to ask it, as there is no clear-cut answer. That said, I'm trying to give it a shot.
Django also follows the MVC design pattern, but the naming is a bit different.
Django Models -> MVC Models
Django Views -> MVC Controllers
Django Templates -> MVC Views
It is often referred to as MTV instead of MVC. But that's not the end of the story, because many people think it is a bad idea to put too much business logic in the views, for reasons like testability and reusability. There are two common approaches to this issue:
fat models: you put all your business logic inside the models
services: you have separate modules containing methods/classes for your business logic
Personally, I have worked with both and had better experiences with the services approach.
The equivalent to a DAO in Django is probably the Django ORM. Note that this is really only an abstraction layer for the supported relational databases. If you want to use another datasource like a NoSQL DB or a REST API, you have to roll your own solution or look for third-party packages.
Java can only have one public class per file and they must have the same name. Python does not have this limitation, so it is indeed a best-practice to have multiple classes per file (.py files are called modules). If a module/file becomes too large, you can turn it into a package (a directory with a __init__.py file) containing several modules (and/or sub-packages).
The differentation between app and project can be confusing, so I have written a whole article about Django's naming scheme. A Django app is a Python package, but they are usually organized by domain. E.g. in a library management system, your library project might have an app catalogue to manage the inventory, and a checkout app to manage the process of checking out books.
Finally, if you are specifically aiming to build a REST API, I highly recommend you have a look at Django REST Framework.
We're looking for a general RESTful API solution for our Django project. We would use the API at first for Ajax calls on the web site and later for mobile apps, external apps and things like that.
I found two modules which seem to be widely used. django-piston and django-tastypie
From what I read, piston seems to be older and thus more mature but maybe a bit outdated?!
While tastypie is relatively new and nicely documented.
What would be the best thing to go with? django-piston or django-tastypie?
Important for us (ordered by priority): Continuous maintenance of the source, documentation, stability, ease of use.
EDIT (2013 Jul 16th):
Now over a year later we have a clear winner. At first we went with tastypie. Which we kinda liked. But after half a year or so we switched to the then upcoming django-rest-framework and never looked back.
What we like most about it:
Nice documentation
Active community
Clean design (build upon django's class based views)
Browsable API for development and debugging
We rely on the API heavily so support (in the future) is one of our main concerns. We met the maintainer - Tom Christie - (on and offline) and he seems very committed to the project. So we feel very comfortable using the django-rest-framework.
A good resource to compare them is http://www.djangopackages.com/grids/g/api/
Django-tastypie sure is the save choice right now.
Personally I'd advocate a look at django-rest-framework if you use django 1.3, because it uses the new class based views. djangopackages.com's comparison page shows it has good participation and activity. And, wow, it sure has a nice browsable interface to the API.
I have no experience with this, but I trust Pydanny in this:
django-piston has been barely supported for nearly two years. That is
an eternity, and the number of forks to address multiple issues is a
cause for alarm. Because of that, in it's place at this time I
recommend django-tastypie. It is up-to-date, has very good
documentation, supports OAUTH, and scored second place in the Django
Packages thunderdome (it got nearly 3x as many points!). Another tool
to consider is Django Rest Framework, which is as good as
django-tastypie but lacks the OAUTH support.
On the django-piston front, Joshua Ginsberg has taken over the reins
and we should hopefully see some movement again. In which case I'll be
able to remove this section of the blog post.
from Pydanny's blog.
Having implemented API's with django Piston, tastypie and django webmachine Django tastypie rocks! Having said that, I think that while tastypie is really good when your API is modelled close to your models, it's a little bit more complicated to do things once you want to move out of the box. There are workarounds to some issues, with others you have to do more bending than building. It will, probably, still cover 90% of django use cases.
Afaik Webmachine was modelled after the popular erlang webmachine, but hasn't been very active lately. So that leaves piston, which is picking up some activity, and tastypie, that has a lot of momentum and activity. Piston is a bit more flexible, but tastypie is moving very fast and in my opinion has a really easy API.
My recommendation would be to quicky implement a prototype of the API in tastypie, and see if it covers what you want to do.
Django REST framework 2.0 was anounced in Oct 2012 and now supports OAuth out of the box. What I really like is the Web browseable API, which is really helpful when developing your API, but also when someone implements your API. It's kind of comparable with using the Django admin site for inspecting your models' structure and data, but then for your API. Also the documentation is very good.
From their website:
Django REST framework is a powerful and flexible toolkit that makes it
easy to build Web APIs.
Some reasons you might want to use REST framework:
The Web browseable API is a huge usability win for your developers.
Authentication policies including OAuth1a and OAuth2 out of the box.
Serialization that supports both ORM and non-ORM data sources.
Customizable all the way down - just use regular function-based views if you don't need the more powerful features.
Extensive documentation, and great community support.
Check out their Quickstart guide to get a quick idea of how it works.