We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Python REST frameworks review

00:00

Formale Metadaten

Titel
Python REST frameworks review
Serientitel
Anzahl der Teile
160
Autor
Lizenz
CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Python REST frameworks review [EuroPython 2017 - Talk - 2017-07-10 - PyCharm Room] [Rimini, Italy] Number of libraries for building RESTful web applications is growing up. Selecting best framework becomes hard decision for web developers. During the presentation I will go through best libraries I can recommend for building RESTful web applications. Selection of libraries will be subjective, based on my experience with building microservices in Python. I will share code examples, weaknesses and strengths for each library. I hope everyone will find something that best suits his needs
95
Vorschaubild
1:04:08
102
119
Vorschaubild
1:00:51
REST <Informatik>SoftwareCOMSoftwareentwicklerFramework <Informatik>Ultraviolett-PhotoelektronenspektroskopieURLSummierbarkeitDesintegration <Mathematik>SichtenkonzeptRouterFarbverwaltungssystemPERM <Computer>DatenmodellExogene VariableLASER <Mikrocomputer>RuhmasseE-MailMailing-ListeWeb-SeiteEndliche ModelltheorieAbfrageObjekt <Kategorie>Meta-TagDatenfeldSoftwareNummernsystemMapping <Computergraphik>DefaultAttributierte GrammatikProdukt <Mathematik>ClientKlasse <Mathematik>Cluster <Rechnernetz>SoundverarbeitungSystemaufrufResultanteCASE <Informatik>Schreib-Lese-KopfData MiningSichtenkonzeptSchnittmengePartielle DifferentiationMereologieMultiplikationsoperatorBitEndliche ModelltheorieOrdnung <Mathematik>WarteschlangeCoxeter-GruppePunktFramework <Informatik>AntwortfunktionIntegralE-MailWeb-SeiteEinflussgrößeSprachsyntheseSoftwareschwachstelleDifferenteMailing-ListeIterationPatch <Software>DatensatzProjektive EbeneREST <Informatik>RechenwerkDatenverwaltungSystemplattformSuite <Programmpaket>ComputeranimationVorlesung/KonferenzXML
MusterspracheURLGruppenkeimRouterGruppenoperationAuswahlaxiomREST <Informatik>Gewicht <Ausgleichsrechnung>ParserKommensurabilitätMessage-PassingKartesische KoordinatenFramework <Informatik>Serielle SchnittstelleSchlüsselverwaltungGeradeInstantiierungGamecontrollerNamensraumAutorisierungGruppenoperationProgrammbibliothekTypentheorieMailing-ListeAttributierte GrammatikREST <Informatik>SichtenkonzeptRegulärer Ausdruck <Textverarbeitung>CASE <Informatik>RechenschieberWeg <Topologie>Data DictionaryKreisbogenParametersystemBenutzerbeteiligungVariableElektronische PublikationDatenstrukturSpezifisches VolumenServerHoaxGewicht <Ausgleichsrechnung>Metropolitan area networkPhysikalisches SystemKontrollstrukturKlasse <Mathematik>MinimumArithmetischer AusdruckTermForcingDatenflussAuswahlaxiomFehlermeldungFramework <Informatik>Arithmetisches MittelWeb-SeiteWeb SiteMessage-PassingRelativitätstheorieBaumechanik
Große VereinheitlichungKommensurabilitätLastFramework <Informatik>DruckspannungDatenstrukturArithmetisches MittelMaßerweiterungMetropolitan area networkSerielle SchnittstelleProgrammbibliothekGamecontrollerNamensraumMultiplikationsoperatorBenchmarkCASE <Informatik>Kategorie <Mathematik>BenutzerfreundlichkeitREST <Informatik>Rechter WinkelMessage-PassingRelativitätstheorieLastStreaming <Kommunikationstechnik>Produkt <Mathematik>MinimumGefrierenRechenwerkExogene VariableVererbungshierarchieQuick-SortWeb-SeiteGüte der AnpassungCodierungObjekt <Kategorie>PunktFront-End <Software>VersionsverwaltungSpeicherabzugAttributierte GrammatikMusterspracheAutorisierung
ZahlenbereichFramework <Informatik>RohdatenAuswahlaxiomREST <Informatik>Framework <Informatik>REST <Informatik>WasserdampftafelNummernsystemLie-GruppeGebäude <Mathematik>ProgrammbibliothekUltraviolett-PhotoelektronenspektroskopieRadiusMultiplikationsoperatorDimensionsanalyseDifferenteAuswahlaxiom
Framework <Informatik>REST <Informatik>Gebäude <Mathematik>MultiplikationsoperatorCoxeter-GruppeProgrammbibliothekEndliche ModelltheorieBenutzerbeteiligungEinfügungsdämpfungUmwandlungsenthalpieGenerator <Informatik>KonditionszahlProjektive EbeneReelle ZahlVorlesung/Konferenz
REST <Informatik>Framework <Informatik>Besprechung/Interview
Framework <Informatik>REST <Informatik>KoroutineBenutzerbeteiligungBesprechung/Interview
Dienst <Informatik>Analytische MengeFramework <Informatik>Besprechung/Interview
Transkript: Englisch(automatisch erzeugt)
Welcome everyone. My name is Serafo Novitski, and currently I'm working at STIX Next. Here I'm, because this is a software house, currently I'm working for a client who is one of the biggest marketing agencies,
and here we are making the assets management platform for them, based on microservices mostly. So this is the agenda. I will start with a short introduction, the goal.
Then the main part of the presentation is about three frameworks. Next, I will briefly describe the next three. Each part, each framework will be presented the features,
the crude example, and the reason. I will finish with the summary and the question and answers session.
Okay, so every time when I was designing the microservice and or I was a witness of the designing new products, I've always seen the same discussions. Which tool are best for our needs,
will be best for the product? And the answer is quite often like the same that we used recently. So the best solutions are that we already know,
that are already discovered, and if there are business requirements that the business needed as soon as possible, then we cut off and go back to the solutions that we already know.
And I'd like to share with you the frameworks that I checked in order to do something different. So maybe you will be able to answer
the following question, which framework best suits to my needs? And I will start with the Django REST framework. DRF is one of the first that I've learned.
The framework has been designed for Django. It has great integration with Django. The documentation is also really nice. The framework is complex, so it also needs the complex documentation,
and this is what can you find here. And another feature is the Browseable API. So DRF allows you to live check your endpoints on the webpage,
so you don't need any Postman or any other tool to check the request. This is the simple viewsets. So in DRF, you could create the endpoints by two ways.
One of them is using API views, and another one is to use the viewsets, and the viewsets is like managing the API views. So here, this is an example of user viewsets.
We have two methods which simply say what has been returned on list methods, it will be the result of the list endpoint, and what's returned in retrieve
will be returned in this case, user details. So you simply return the response and put the data that you want to have, that you want to your client read.
And in this case, it's the iteration through the user, so in list view, you get the user names list, and in retrieve, you get the user name, email, and full name keys, with the values for particular user.
Metasemapping for viewsets, you already know the lists and retrieve, there is also create for posts request, so list is for get request on collection,
retrieve is a get request on item, updates and partial update is put and patch mapping, and this row is just the delete. By default, you get here the PK, but you can simply change it through the attributes in your viewsets.
So this is the model-based viewsets, this is why I'm using the DRF for one of the projects. If you have the project where there is a lot of models
that you want to overlap with the crude, then by simple declaring the second class, the first class is serializer,
second class is just a whole unit to wrap the model to your API, and by default, you get full crude,
create, read, update, and delete, and how to set up the URLs, when you're using the viewsets, you can use the routers, and this is like you register a new viewset,
but you can also do this with the known from Django way, so by, because the viewset is also the view class, so you can use the as view and put it,
the URL that you really need, and this is more a detailed example, so we have two nodes, one for user, one for groups, and by registering the user and group routers,
you will get the pattern-like users, this is based from the first regular expression from the first argument, or in case when you need detailed action,
you get the PK by default, but if you change it, you can get whatever you want, and here you also have the name, so you can use it all around your Django app,
or even in the other APIs, so if you already use Django, and you need crude as I mentioned for models, the DRF will do for this,
and it is the obvious choice, another one, Flask RESTful, so this is the library created for Flask, surprise, compared to the Django REST framework, it contains the minimum,
actually the ORM is not included, as on Flask, you can decide what to use, it's great for building lightweights APIs, and better way to organize your resources, to be honest, this is the biggest value for using it,
so I will go through a few examples, but actually it's one example, so you can treat those slides like one page, so start from the top,
just keep track on the users, which is currently the variable in this file, so we have the user's dictionary structure, and I will save the users by the key,
the identifier, and the details in value, and what is really nice and well known, the Flask RESTful use the request parser,
it works really similar to ARC parser, so here you can set the arguments that will be used, and you can say what type of it is,
or is it required or no, so let's go to the resources, and here we have the methods called get and post, so this will be the list resource, the collection resource, and here in get request we will return the list
of the users, which is only the attributes from the previous slide, and on post we will get the user name,
and save it to the already existing user, the existing dictionary, here you can see that the serialization is behind,
so you don't need to remember about the serialization on your site, so the dict will be just converted to the JSON,
and this is the user resource, so this is for item, and here you also have now get, delete, and put, it's more clear than the usage for the RF, but anyway, here you have,
for get you rise, actually use the abort, this is the method from Flask RESTful, which throws 404 and the particular message, then on delete we remove the user
by the key from the dict, for put we just overwrite the value for this one, and this is the place where we do all the setup, so the first and last line is Flask,
and this is all you need, is just create a new API instance on this Flask app, and add the resources, you have the full control of naming,
of namespace on it, so no one will do this for you, and so far if you have Flask, it makes sense to replace your API written in Flask,
to Flask RESTful, to have things organized, but if it's still not what we really need, let's go to the next one, so Flake on, Flake on is working on C Python,
actually it was on Python, but the author recommends to use it on it, because of the performance, so the Flake on is minimalistic web framework,
and it's reliable and high performance, so there are a bunch of benchmarks on the Flake on page,
so the author really did great work with optimizing this one, so the reason for this is just focus on one single case, this HTTP APIs,
we'll go quite similar example, then we go through the RESTful APIs, Flask RESTful, so starting from the top, we have the same user structure, and let's go to the resource,
you can see that I only imported the Flake on JSON libraries, so the name convention for the methods is quite similar, but you need to add on prefix,
so on get you set the body, this is quite different than in Flask RESTful, this is because you get in recu and res, the reference to the objects, so we don't return anything,
instead of none, so it's enough to just set the body attribute with the values, and here there is no serialization, so you need to do JSON dump on this,
and on posts methods, this code make more complicated, but it may look more complicated, but it still do the same, so we extract the body from the stream,
then serialize the body, and then do the same, get the, actually pop the user name, and show the proper message if the user exists,
and set up the value if it doesn't, so here we can see that there is the return, this is because the way of assigning the attributes to the request and the responses,
so if I would forget about this, then if the user won't exist, the code will try to set the user anyway, this is the user resource,
and here we have quite similar situation, so when the user doesn't exist, so you get the 404 and the message,
on delete, we remove the user from the dict, and on put, we update the user, and this is the same code is actually repeating here, so the point of serialization,
so every time you need to read from a stream, loads it, the JSON, and then do what you want, so here you get a few additional steps,
this is the way of setting up the URLs, here we also have the full control of namespace, so the best practice is to keep it in one place, or just share the way of sharing the URL,
and share your pattern with your colleges, so this is great if everything that you do is the API,
and you're really focused on the performance, so there are a few more libraries that I've tried, and I guess I don't have enough time to go through every of this,
that's why it's together, so AVE, this is the so-called framework for human beings, so the general idea is to easily build and deploy customizable APIs,
a lot of things are set up in just JSON structure, or just the DIG structure in Python, and this has the native support for MongoDB, but as extensions, it can be used for SQL,
Elasticsearch, and other backends. Another one, the TastyPy, this is a few years ago,
it was, I used it for one of the Django projects, and it worked very well, unfortunately it's not,
it's not developed anymore, so the version freeze on 0.13, it do simply things like the DRF, I mean it really did a lot of for you,
but you had serializer and Vue in one class, and AP star, this is actually, this is not a framework for building a successful application, it's just a framework for building any APIs, but I think it's worth mention,
and maybe you would be interested in more details on it, so this is the outer is the same for DRF, and AP star is framework designed for Python 3,
light, and in general helps building the APIs, so if you want to follow RESTful pattern, then you need to take care of it on your own. And summary, so the number of RESTful framework
is still limited, and this is a good thing, and also the bad thing, so the bad, because we may expect any other,
any other libraries or frameworks that we could use, but from the other hand, we have great combine, which is Django REST framework for Django apps, and there is currently no competition for this.
The Flacon is still best choice for microservices, I didn't find any other focused on the performance, and things worth mention is that libraries just supports
you with writing RESTful APIs, but big frameworks create APIs for you, and this is the difference between the frameworks and libraries, and currently I can say
that the framework is only the DRF from those list. So thank you.
So if you have any questions, or just you want to share the libraries that you know and I missed, feel free. Yeah, if you have a question, please raise your hand, we have time for a couple of them.
You and me, yeah, thank you for your talk. Just a quick question. Have you, I was wondering why you haven't considered a pyramid or pyramid framework in your presentation?
Maybe there is a good reason for it, but was just, yeah, wondering why. As far as I know, the pyramids, I think that there is, okay, so it's more the web framework, rather than the framework or the library
focused on building the RESTful APIs, so that's why I skip it. But, yeah, so does it satisfy you? There is one more great framework. It's called Flask-REST Plus.
It's written on top of Flask RESTful. The most tasty feature of it is model specification, and Swagger documentation generation. Django REST framework has Django REST Swagger,
but it doesn't handle models generation in Swagger specification. And Flask-REST Plus does it. And I consider using it in real project, and it's really great. Okay, thanks.
Hi, so one thing, one more framework that we use that is not that RESTful one, but we use a lot of cherry pie, because it's, I think, the most lightweight web framework that's available, and it works pretty fine with the REST APIs. But that was what I wanted to mention, and I have a question, because those frameworks,
they have pretty useful tools, like ORM or routing or other stuff, but I think that the really important thing when designing RESTful APIs is the RESTfulness of them. So the question is, do you use Swagger, or any other tools for keeping the RESTful API
being the RESTful, or what's your experience on that? Yeah, so for microservices, we use the Swagger, as you said, but for example, in the way more monolithic service,
based on Django, the browser-able API were fine for us. So yeah, but in general, that's it.
And what's the name of this framework that you started with? Chirpy. Chirpy, okay. Thanks. Thank you.