Django REST framework vs Swagger UI: What are the differences?
Django REST framework belongs to "Microframeworks (Backend)" category of the tech stack, while Swagger UI can be primarily classified under "Documentation as a Service & Tools".
"Browsable api" is the primary reason why developers consider Django REST framework over the competitors, whereas "Open Source" was stated as the key factor in picking Swagger UI.
Django REST framework is an open source tool with 14.7K GitHub stars and 4.33K GitHub forks. Here's a link to Django REST framework's open source repository on GitHub.
According to the StackShare community, Swagger UI has a broader approval, being mentioned in 205 company stacks & 107 developers stacks; compared to Django REST framework, which is listed in 159 company stacks and 79 developer stacks.
What is Django REST framework?
What is Swagger UI?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Swagger UI?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about 600 lines of code left from the original Pylons framework that actually ran).
One of the things that has been really fantastic about Django is that we're still happily using it for the vast majority of code in the project, and every time Django comes out with a new release, I read the changelog and get excited about several improvements that actually make my life better. While Django has made some design decisions that I don't agree with (e.g. I'm not a fan of Django REST framework, and think it makes life more difficult), Django also makes it easy to do your own thing, which we've done to great effect (see the linked article for details on our
Overall I think we've gotten a ton of value out of Python and Django and would recommend it to anyone starting a new full-featured web application project today.
We just launched the Segment Config API (try it out for yourself here) — a set of public REST APIs that enable you to manage your Segment configuration. A public API is only as good as its #documentation. For the API reference doc we are using Postman.
Postman is an “API development environment”. You download the desktop app, and build API requests by URL and payload. Over time you can build up a set of requests and organize them into a “Postman Collection”. You can generalize a collection with “collection variables”. This allows you to parameterize things like
workspace_name so a user can fill their own values in before making an API call. This makes it possible to use Postman for one-off API tasks instead of writing code.
Then you can add Markdown content to the entire collection, a folder of related methods, and/or every API method to explain how the APIs work. You can publish a collection and easily share it with a URL.
This turns Postman from a personal #API utility to full-blown public interactive API documentation. The result is a great looking web page with all the API calls, docs and sample requests and responses in one place. Check out the results here.
Postman’s powers don’t end here. You can automate Postman with “test scripts” and have it periodically run a collection scripts as “monitors”. We now have #QA around all the APIs in public docs to make sure they are always correct
Along the way we tried other techniques for documenting APIs like ReadMe.io or Swagger UI. These required a lot of effort to customize.
Writing and maintaining a Postman collection takes some work, but the resulting documentation site, interactivity and API testing tools are well worth it.
Two weeks ago we released the public API for Checkly. We already had an API that was serving our frontend Vue.js app. We decided to create an new set of API endpoints and not reuse the already existing one. The blog post linked below details what parts we needed to refactor, what parts we added and how we handled generating API documentation. More specifically, the post dives into:
- Refactoring the existing Hapi.js based API
- API key based authentication
- Refactoring models with Objection.js
- Validating plan limits
- Generating Swagger & Slate based documentation
Django REST delivered all the content to the BI, making calls to the Postgres DB, aggregating numeric data, and automatically associating data models at the time of row creation.
Instead of using Django for both back and frontend, I use DRF to layout an API that ReactJs can pull data from. Easy to setup, well documented, and works seamlessly with React.
django에서 api를 만드는데 최고의 framework라고 생각합니다. 아직은 tutorial 수준의 class base view, function base view 수준으로 사용합니다.
하지만 현재 진행중인 프로젝트의 심화로 REST framework를 심도있게 다룰 예정입니다.
Really great framework for building RESTful APIs. Lots of plugins for it!