Kolv är ett lätt Python-webbramverk som vanligtvis används för att bygga REST API: er och mikrotjänster. Dess minimala kärna och flexibla arkitektur gör det möjligt för utvecklare att designa API: er utan att begränsas av strikta projektstrukturer.
I den här guiden bygger du ett enkelt REST API med hjälp av Flask, inklusive:
I slutet av denna handledning kommer du att förstå hur du designar och strukturerar ett produktionsklar Flask API.
Flask är ett lätt Python-webbramverk som används för att bygga API: er och webbapplikationer genom att definiera HTTP-rutter som returnerar JSON- eller HTML-svar.
Ett ramverk är ett bibliotek som används av utvecklare för att bygga och underhålla pålitliga och skalbara webbapplikationer. Det finns flera ramverk tillgänglig för Python, som Tornado, Pyramid och naturligtvis Django (som ofta jämförs med Flask).
Flask är ett Python-mikroramverk för webbutveckling. Trots att den är byggd med en liten kärna och betraktas som ett mycket lätt Web Server Gateway Interface (WSGI), sticker Flask ut för sin lättutökade filosofi. Den har utformats för att skala upp till komplexa applikationer och för att stödja en enkel och snabb start.
Dessutom är en annan stor fördel med Flask dess funktionalitet. Även om det ger förslag kräver Flask inte obligatoriskt projektlayouter eller andra beroenden. Istället tillåter det utvecklare att välja de bibliotek och verktyg de vill använda och har dessutom olika förlängningar tillgängliga, som tillhandahålls av samhället.
API är en förkortning av Application Programming Interface, vilket betyder att det i princip är hur du kommunicerar med en ansökan. Ett REST (Representational State Transfer) API tillåter kommunikation mellan system med standard HTTP-metoder och motsvarar en arkitektonisk stil som syftar till statslös kommunikation och skiljer klient- och serverproblem. Det utbyter vanligtvis data i JSON-format och fungerar med slutpunkter som motsvarar åtgärder som Skapa (POST), Läs (GET), Uppdatera (PUT eller PATCH) och Radera (DELETE). REST API: er används ofta för sin enkelhet, skalbarhet och kompatibilitet med ett brett utbud av klienter och plattformar.
Den REST API på denna övning kommer att skapa en falsk implementering av CRUD-åtgärder över en enhet. Ett API med CRUD tillåter Skapa, Läs, Uppdatera och Ta bort operationer över programmets element.
Den här artikeln guidar dig genom de första stegen för att skapa ett REST API med Flask.
I den här handledningen kommer du att bygga ett enkelt REST API med Flask och Python som innehåller:
Det här exemplet visar de viktigaste komponenterna som behövs för att skapa ett produktionsklart backend-API.
Du måste ha Python installerat på den aktuella datorn. Koden som presenteras kommer att överväga Python3. Om du vill använda Python2 och/eller följer denna procedur i en Windows-dator, följ instruktionerna som presenteras i Installationsguide för kolv.
Låt oss börja med skapa en katalog för att lagra projektet. I katalogen du vill ha ditt projekt kör du följande kommandon på skalet:
Vi har skapat flask_demo katalog och flyttade in den. Innan vi börjar installera beroenden, låt oss skapa en virtuell miljö genom att köra följande kommando:
Detta skapar en mapp i ditt projekt med namnet .venv. Efter det måste vi aktivera respektive miljö genom att köra:
Detta innebär att vi nu överväger venv virtuell miljö när du kör någon Python-kod. Det kan vara viktigt att ange vilken miljö du överväger när du kör den i din IDE.
Se till att du har miljön aktiv innan du följer nästa steg. Du kan kontrollera om du befinner dig i miljön genom att titta på vänster sida av konsolen. Om det finns namnet på den virtuella miljön inom parenteser är du redo att gå.
Om du vill inaktivera miljön, kör bara följande kommando:
Ett typiskt Flask API-utvecklingsarbetsflöde inkluderar:
Denna struktur hjälper till att hålla backend-tjänster organiserade och lättare att underhålla.
I föregående exempel lagrade API data i en Python-lista. Även om detta är användbart för att demonstrera CRUD-slutpunkter, är det inte lämpligt för verkliga applikationer eftersom data försvinner när servern startas om.
I praktiken lagrar API: er data i en databas så att den kvarstår mellan förfrågningar och applikationsomstart. I det här avsnittet kommer vi att använda SQLite och SQLAkemi för att bygga ett enkelt databasbaserat API.
SQLite är en lättviktig databas som inte kräver någon separat server, vilket gör den idealisk för självstudier och små applikationer.
Installera först de nödvändiga beroenden.
Kör följande kommando:
pip install sqlalchemy flask-sqlalchemy
Om du hanterar beroenden med en requirements.txt fil, lägg till:
Flask
sqlalchemy
flask-sqlalchemy
I den här inställningen:
Konfigurera sedan Flask för att ansluta till SQLite-databasen.
from flask import Flask, request, jsonify
from flask_sqlalchemy import SQLAlchemy
app = Flask(__name__)
app.config["SQLALCHEMY_DATABASE_URI"] = "sqlite:///items.db"
app.config["SQLALCHEMY_TRACK_MODIFICATIONS"] = False
db = SQLAlchemy(app)
Här definierar vi databasanslutningssträngen:
sqlite: ///items.db
Detta skapar en lokal SQLite-databasfil med namnet items.db i projektkatalogen.
Skapa sedan en modell som representerar strukturen i databastabellen.
class Item(db.Model):
id = db.Column(db.Integer, primary_key=True)
name = db.Column(db.String(100), nullable=False)
price = db.Column(db.Float, nullable=False)
def to_dict(self):
return {
"id": self.id,
"name": self.name,
"price": self.price
}
Den Objekt modellen definierar tre fält:
Den till_dict () metoden konverterar databasobjektet till en JSON-serialiserbar ordlista.
Innan du kör API, skapa databastabellerna med SQLAlchemy.
@app.route("/items", methods=["GET"])
def get_items():
items = Item.query.all()
return jsonify([item.to_dict() for item in items])
Denna slutpunkt hämtar alla objekt som lagras i databasen.
@app.route("/items", methods=["POST"])
def create_item():
data = request.get_json()
if not data or "name" not in data or "price" not in data:
return jsonify({"error": "Name and price are required"}), 400
item = Item(name=data["name"], price=data["price"])
db.session.add(item)
db.session.commit()
return jsonify(item.to_dict()), 201
Denna slutpunkt:
@app.route("/items/<int:item_id>", methods=["GET"])
def get_item(item_id):
item = Item.query.get_or_404(item_id)
return jsonify(item.to_dict())
Denna slutpunkt hämtar ett specifikt objekt med dess ID.
Om objektet inte finns returnerar Flask automatiskt en 404-fel.
@app.route("/items/<int:item_id>", methods=["PUT"])
def update_item(item_id):
item = Item.query.get_or_404(item_id)
data = request.get_json()
if not data:
return jsonify({"error": "Request body is required"}), 400
item.name = data.get("name", item.name)
item.price = data.get("price", item.price)
db.session.commit()
return jsonify(item.to_dict())
Den här slutpunkten uppdaterar ett befintligt objekt.
Endast de angivna fälten ändras.
@app.route("/items/<int:item_id>", methods=["DELETE"])
def delete_item(item_id):
item = Item.query.get_or_404(item_id)
db.session.delete(item)
db.session.commit()
return jsonify({"message": "Item deleted successfully"})
Den här slutpunkten tar bort det angivna objektet från databasen.
Starta utvecklingsservern för Flask:
python app.py
Ditt API kommer nu att finnas tillgängligt lokalt.
Begäran:
{
"name": "Keyboard",
"price": 49.99
}
Svar:
{
"id": 1,
"name": "Keyboard",
"price": 49.99
}
Svar:
[
{
"id": 1,
"name": "Keyboard",
"price": 49.99
}
]
Minneslistor är användbara för enkla demonstrationer men har flera begränsningar:
Genom att använda en databas som SQLite kan API lagra och hämta ihållande data, vilket gör att applikationen beter sig mer som en riktig backend-tjänst.
För produktionssystem använder utvecklare vanligtvis databaser som PostgreSQL, MySQL, eller MongoDB, men den övergripande API-strukturen förblir densamma.
För små applikationer eller självstudier är det vanligt att hålla hela API i bara några filer. Detta tillvägagångssätt håller installationen enkel och lätt att förstå.
En typisk Flask API-struktur för nybörjare kan se ut så här:
flask-api/
├── app.py
├── requirements.txt
├── models.py
├── routes.py
├── schemas.py
└── items.db
I denna struktur:
Denna layout är lätt att följa och fungerar bra för små API: er, prototyper och inlärningsprojekt.
Men när applikationen växer kan denna struktur bli svår att underhålla.
För att göra strukturen lättare att förstå, här är hur varje fil kan användas.
app.pyDen här filen skapar Flask-programmet, konfigurerar databasen och registrerar rutterna.
from flask import Flask
from flask_sqlalchemy import SQLAlchemy
from flask_smorest import Api
db = SQLAlchemy()
def create_app():
app = Flask(__name__)
app.config["SQLALCHEMY_DATABASE_URI"] = "sqlite:///items.db"
app.config["SQLALCHEMY_TRACK_MODIFICATIONS"] = False
app.config["API_TITLE"] = "Flask API Demo"
app.config["API_VERSION"] = "v1"
app.config["OPENAPI_VERSION"] = "3.0.3"
app.config["OPENAPI_URL_PREFIX"] = "/"
app.config["OPENAPI_SWAGGER_UI_PATH"] = "/docs"
app.config["OPENAPI_SWAGGER_UI_URL"] = "https://cdn.jsdelivr.net/npm/swagger-ui-dist/"
db.init_app(app)
api = Api(app)
from routes import blp
api.register_blueprint(blp)
with app.app_context():
db.create_all()
return app
app = create_app()
if __name__ == "__main__":
app.run(debug=True)
models.pyDen här filen definierar databasmodellen.
from app import db
class Item(db.Model):
id = db.Column(db.Integer, primary_key=True)
name = db.Column(db.String(100), nullable=False)
price = db.Column(db.Float, nullable=False)
routes.pyDen här filen innehåller API-slutpunkterna.
from flask.views import MethodView
from flask_smorest import Blueprint
from models import Item
from schemas import ItemSchema
from app import db
blp = Blueprint(
"items",
"items",
url_prefix="/items",
description="Operations on items"
)
@blp.route("/")
class ItemsResource(MethodView):
@blp.response(200, ItemSchema(many=True))
def get(self):
return Item.query.all()
@blp.arguments(ItemSchema)
@blp.response(201, ItemSchema)
def post(self, new_item):
item = Item(**new_item)
db.session.add(item)
db.session.commit()
return item
Att separera programmet i filer ger flera fördelar:
Om du till exempel senare lägger till autentisering, användare eller beställningar kan du utöka strukturen utan att skriva om hela projektet.
Större applikationer drar nytta av att organisera koden i paket. Detta separerar olika delar av systemet, vilket gör projektet lättare att skala och underhålla.
En mer produktionsklar Flask API-struktur kan se ut så här:
För större projekt är det vanligt att organisera koden i mappar snarare än enskilda filer på toppnivå.
En mer skalbar struktur kan se ut så här:
flask-api/
├── app/
│ ├── __init__.py
│ ├── models/
│ │ └── item.py
│ ├── routes/
│ │ └── items.py
│ └── schemas/
│ └── item.py
├── requirements.txt
└── run.py
I denna arkitektur:
Detta modulära tillvägagångssätt gör det lättare att:
Bästa praxis
När du bygger ett Flask API är det en bra idé att börja med en enkel struktur och utöka den först när applikationen växer. För små projekt räcker det ofta med några tydligt namngivna filer. För större API:er blir underhållet mycket enklare att flytta till en paketbaserad layout.
En ren projektstruktur hjälper andra utvecklare att förstå koden snabbt och gör applikationen lättare att utöka i framtiden.
Innan vi presenterar andra Flask-styrkor, låt oss prata om ritningar. En ritning är ett objekt som mycket liknar ett Flask-applikationsobjekt, men istället för att skapa ett nytt tillåter det förlängningen av det aktuella programmet. Detta kan vara användbart om du vill skapa flera versioner av ett API eller helt enkelt dela upp tjänster inom samma applikation.
Vi kommer att använda denna klasstyp för att presentera olika användningsfallscenarier för en Flask-applikation. Låt oss konvertera koden ovan för att infogas i en ritning och laddas i huvudapplikationen.
Skapa en ny mapp med namnet ritningar för att börja infoga blueprint-moduler när vi går vidare i blogginlägget. Inuti den skapar du en mapp som heter grundläggande slutpunkter och sedan en fil som heter __init__.py:
# blueprints/basic_endpoints/__init__.py
from flask import Blueprint, jsonify
basic_bp = Blueprint('basic_bp', __name__)
@basic_bp.route('/')
def hello():
return jsonify({'message': 'Hello from a Blueprint!'})
Nu main.py filen behöver bara ladda den skapade ritningen och registrera den till applikationsobjektet:
# main.py
from flask import Flask
from blueprints.basic_endpoints import basic_bp
app = Flask(__name__)
app.register_blueprint(basic_bp)
if __name__ == '__main__':
app.run(debug=True)
Nu ska du ha exakt samma slutpunkter men använda strukturen som tillhandahålls av Blueprints. Detta kommer att göra din applikation enklare att hantera och skala när den växer.
.webp)
När du bygger API:er är det viktigt att validera inkommande förfrågningar och returnera meningsfulla felsvar när något går fel. Utan validering kan ett API acceptera ofullständiga eller ogiltiga data, vilket kan leda till inkonsekventa poster i databasen eller oväntat applikationsbeteende.
Ett väl utformat API bör:
Detta förbättrar tillförlitligheten och gör API enklare för andra utvecklare att använda.
När en klient skickar data till API:et bör servern verifiera att de obligatoriska fälten finns och är korrekt formaterade.
Till exempel, när du skapar ett nytt objekt, begäran bör innehålla både a namn och en pris.
Här är ett enkelt valideringsexempel:
@app.route("/items", methods=["POST"])
def create_item():
data = request.get_json()
if not data:
return jsonify({"error": "Request body must be JSON"}), 400
if "name" not in data or "price" not in data:
return jsonify({"error": "Both 'name' and 'price' fields are required"}), 400
item = Item(name=data["name"], price=data["price"])
db.session.add(item)
db.session.commit()
return jsonify(item.to_dict()), 201
I det här exemplet kontrollerar API:et om:
Om valideringen misslyckas returnerar API:et en 400 Dålig begäran svar.
HTTP-statuskoder hjälper klienter att förstå om en begäran lyckades eller misslyckades.
Några vanliga koder som används i REST API: er inkluderar:
Att använda rätt statuskod hjälper API-konsumenter att hantera svar korrekt.
När en klient begär en resurs som inte finns, API:et ska returnera en 404-fel.
Flask-SQLAlchemy ger en bekväm hjälpare för detta:
item = Item.query.get_or_404(item_id)
Om objektet inte finns returnerar Flask automatiskt ett svar som:
{
"message": "404 Not Found: The requested URL was not found on the server."
}
Detta förhindrar API från att returnera tomma eller vilseledande svar.
I större program är det användbart att definiera globala felhanterare som returnerar konsekventa svar för vanliga fel.
Till exempel:
@app.errorhandler(400)
def bad_request(error):
return jsonify({
"error": "Bad Request",
"message": "The server could not process the request."
}), 400
@app.errorhandler(404)
def not_found(error):
return jsonify({
"error": "Not Found",
"message": "The requested resource was not found."
}), 404
Med dessa hanterare returnerar API:et alltid strukturerade JSON-svar istället för standard HTML-felsidor.
Om en klient försöker skapa ett objekt utan att ange de obligatoriska fälten kan API:et returnera:
{
"error": "Bad Request",
"message": "Both 'name' and 'price' fields are required"
}
Genom att tillhandahålla tydliga felmeddelanden hjälper utvecklare att snabbt förstå vad som gick fel och hur de åtgärdar deras begäran.
Begäran validering och korrekt felhantering är avgörande för att bygga tillförlitliga API:er. De säkerställer att
Dessa metoder anses vara standard i modern API-utveckling och bör inkluderas i alla produktionsklara backend-tjänster.
Moderna API:er bör visa maskinläsbar dokumentation så att utvecklare enkelt kan förstå slutpunkter, begärandeformat och svar. Den mest använda standarden för detta är OpenAPI, som beskriver HTTP-API:er i ett strukturerat format som verktyg kan tolka automatiskt.
I Flask-applikationer är ett bekvämt sätt att generera OpenAPI-dokumentation genom att använda flask-smorest, ett bibliotek som integrerar Flask med OpenAPI 3, begäran om validering och automatisk Swagger UI-dokumentation.
Installera först de nödvändiga paketen.
Kör följande kommando:
pip install flask-smorest marshmallow
Om du föredrar att hantera beroenden med en requirements.txt fil, du kan lägga till följande:
Flask
flask-smorest
marshmallow
I den här inställningen:
Tillsammans tillåter dessa bibliotek Flask-API:er att automatiskt producera interaktiv dokumentation och genomdriva datavalidering.
Innan slutpunkter skapas måste Flask-programmet konfigureras för att generera OpenAPI-dokumentation.
Lägg till följande konfiguration i din Flask-applikation:
from flask import Flask
from flask_smorest import Api
app = Flask(__name__)
app.config["API_TITLE"] = "Flask API Demo"
app.config["API_VERSION"] = "v1"
app.config["OPENAPI_VERSION"] = "3.0.3"
app.config["OPENAPI_URL_PREFIX"] = "/"
app.config["OPENAPI_SWAGGER_UI_PATH"] = "/docs"
app.config["OPENAPI_SWAGGER_UI_URL"] = "https://cdn.jsdelivr.net/npm/swagger-ui-dist/"
api = Api(app)Den här konfigurationen definierar metadata som används för att generera API-dokumentationen.
Nyckelinställningar inkluderar:
När API:et körs kommer dokumentationen att vara tillgänglig på:
http://localhost:5000/docs
API: er bör tydligt definiera strukturen för de data de accepterar och returnerar.
Med flask-smorest görs detta med Marshmallow-scheman.
Skapa ett schema för att beskriva ett objekt i API:et:
from marshmallow import Schema, fields
class ItemSchema(Schema):
name = fields.String(required=True)
price = fields.Float(required=True)
Scheman tjänar flera viktiga syften:
Genom att använda scheman säkerställs att API-slutpunkter beter sig konsekvent och avvisar ogiltiga data.
Skapa sedan API-slutpunkter med hjälp av en Planritning. Med ritningar kan du gruppera relaterade rutter och organisera större API:er.
from flask.views import MethodView
from flask_smorest import Blueprint
blp = Blueprint(
"items",
"items",
url_prefix="/items",
description="Operations on items"
)
items = []
Varje ritning representerar en grupp relaterade slutpunkter som kommer att visas som ett avsnitt i den genererade dokumentationen.
Nu kan vi implementera slutpunkter för att skapa och hämta objekt.
@blp.route("/")
class ItemsResource(MethodView):
@blp.response(200, ItemSchema(many=True))
def get(self):
"""Return all items"""
return items
@blp.arguments(ItemSchema)
@blp.response(201, ItemSchema)
def post(self, new_item):
"""Create a new item"""
items.append(new_item)
return new_item
I det här exemplet:
@blp .argument (ItemSchema) validerar den inkommande förfrågandekroppen.@blp .svar () dokumenterar API-svaret och serialiserar utdata.MetodVisa tillåter gruppering av flera HTTP-metoder under samma rutt.
Dessa dekoratörer uppdaterar automatiskt den genererade OpenAPI-dokumentationen.
När du har definierat slutpunkterna registrerar du ritningen med API-instansen:
api.register_blueprint(blp)
if __name__ == "__main__":
app.run(debug=True)
Registrering av ritningen aktiverar slutpunkterna och säkerställer att de visas i API-dokumentationen.
När programmet körs öppnar du följande URL i din webbläsare:
http://localhost:5000/docs
Du kommer att se en interaktiv Swagger UI-gränssnitt genererad från OpenAPI-specifikationen.
Från det här gränssnittet kan du:
Detta gör API:et lättare att förstå och förenklar integrationen med andra system avsevärt.
Att använda OpenAPI-baserade dokumentationsverktyg som flask-smorest ger flera fördelar:
Eftersom OpenAPI är allmänt använt i branschen kan många utvecklingsverktyg automatiskt generera klientbibliotek, utföra API-testning och validera förfrågningar med samma specifikation.
Av dessa skäl har OpenAPI-dokumentation blivit en standardpraxis när man bygger moderna API: er.
När ditt Flask API är klart, nästa steg är att distribuera det så att det kan nås av användare eller andra tjänster. Medan den inbyggda Flask-servern är användbar för utveckling, kräver produktionsdistributioner en WSGI-server och en webbserver för att hantera trafiken på ett tillförlitligt sätt.
En vanlig driftsättningsinställning inkluderar:
Du kan till exempel köra ett Flask-program i produktion med Gunicorn:
gunicorn -w 4 app:app
I det här kommandot:
-v4 startar fyra arbetsprocesserapp:app refererar till Flask-applikationsobjektet
I moderna miljöer distribueras Flask-API:er ofta med Docker-containrar, vilket förenklar skalning, miljöhantering och kontinuerlig distribution.
De flesta produktions-API:er kräver autentisering för att säkerställa att endast auktoriserade användare eller tjänster kan komma åt skyddade slutpunkter.
Vanliga autentiseringsmetoder inkluderar:
Ett vanligt tillvägagångssätt i Flask API: er är att använda JWT-baserad autentisering. I denna modell:
Auktorisation rubrik med varje förfrågan.
Exempel på rubrik:
Auktorisation: Innehavare <access_token>
Kolvförlängningar som Flask-JWT-förlängd göra det enklare att implementera tokenbaserad autentisering och skydda API-rutter.
Genom att lägga till autentisering säkerställs att:
Trots sin enkelhet är Flask ett extremt kraftfullt Python-webbverktyg. Det är mycket enklare och enklare än att skapa kompletta applikationer på servern. Plus, det kan spara dig så mycket tid!
Förhoppningsvis, i slutet av den här artikeln, har du inga problem med att skapa ett REST API med Flask och automatiskt generera en swagger-dokumentationssida. Dessutom bör du vara bekant med specifika funktioner (som Blueprint-objekt) och ställa in Jinja-mallar.
Flask är fortfarande ett kraftfullt och flexibelt val för att bygga Python API: er. Dess lätta design, modulära arkitektur och omfattande ekosystem gör den väl lämpad för allt från enkla tjänster till skalbara backend-system. I den här guiden utforskade vi hur man bygger ett Flask API steg för steg, inklusive projektinställning, databasintegration, begäran validering, felhantering och OpenAPI-dokumentation, alla viktiga metoder som hjälper till att skapa underhållsbara och produktionsklara API: er.
Om du planerar ett nytt API eller moderniserar en befintlig backend kan det göra stor skillnad att välja rätt arkitektur tidigt. Behöver du hjälp med att bygga eller skala ett Flask-API? Kontakta Imaginary Cloud för att diskutera ditt projekt.
Ett Flask API hänvisar till en RESTful-webbtjänst byggd med Flask-ramverket i Python. Det exponerar slutpunkter som klienter kan interagera med över HTTP, vilket vanligtvis returnerar data i JSON-format.
Ja, Flask kan användas som ett backend-ramverk för att bygga API: er som serverar data till frontend-applikationer eller tjänster från tredje part.
Flask är ett webbramverk, medan REST är en arkitektonisk stil för att designa nätverksapplikationer. Du kan använda Flask för att implementera REST API: er.
Ja, Flask är ett utmärkt val för att bygga API: er på grund av dess enkelhet, flexibilitet och ett brett utbud av tillägg som stöder dokumentation, autentisering och distribution.
Flask används ofta för att bygga REST API: er, mikrotjänster, administratörspaneler, prototypapplikationer och integration med maskininlärningsmodeller.
Ja, Kolv kan användas i produktionen och driver många verkliga webbapplikationer och API: er. Medan den inbyggda Flask-utvecklingsservern endast är avsedd för utveckling, använder produktionsdistributioner vanligtvis en WSGI-server som Gunicorn eller uWSGI bakom en webbserver som Nginx eller Apache.
Med rätt konfiguration kan Flask-applikationer skalas effektivt och stödja produktionsarbetsbelastningar, särskilt när de kombineras med verktyg som Docker, omvända proxyer och databastjänster.
Ett Flask-API distribueras vanligtvis med hjälp av en WSGI-server och en omvänd proxy.
De grundläggande distributionsstegen inkluderar:
Ett vanligt distributionskommando som använder Gunicorn är till exempel:
gunicorn -w 4 app: app
I modern infrastruktur distribueras Flask API: er ofta med Docker-containrar och molnplattformar som AWS, Azure eller Google Cloud.
Den största skillnaden mellan Flask och Django REST Framework (DRF) är nivån på struktur och inbyggd funktionalitet.
Kolv är ett lätt och flexibelt mikroramverk som gör det möjligt för utvecklare att välja sina egna bibliotek och arkitektur. Det ger minimala inbyggda funktioner och är mycket anpassningsbar.
Django REST-ramverk, å andra sidan, är ett fullfjädrat ramverk byggt ovanpå Django som innehåller inbyggda verktyg för autentisering, serialisering, behörigheter och API-vyer.
I allmänhet:
.webp)
Associerad utvecklare som arbetar mest med Backend-teknik. En entreprenör med datavetenskapligt intresse. Kärlek till sport, ljudböcker, kaffe och memes!
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
