Django Rest Framework (DRF)
در درس های رایگان DRF حداقل نیازهایی که برای کار در شرکت ها و یا انجام پروژه ها نیاز دارید، ارائه شده است.
7
درس
- معرفی Django Rest Framework پس از ساخت مدلها در جنگو، اغلب نیاز میشود که دادهها در اختیار برنامههای موبایل یا فرانتاندهایی مانند React قرار بگیرد. جنگو به صورت پیشفرض سازوکاری اختصاصی برای این نوع ارتباطات فراهم نمیکند. در چنین شرایطی، نیاز به یک واسط داریم. واسطی که مدلها را به خروجی JSON تبدیل کند. درخواستهای GET و POST را مدیریت نماید. و امکان ارتباط اپلیکیشنهای دیگر با سایت را فراهم سازد. به این واسط، API گفته میشود. Django REST Framework (یا به اختصار DRF) مجموعهای از ابزارهای آماده برای ساخت همین نوع واسطهاست. بدون اینکه توسعهدهنده مجبور باشد از صفر منطق کوئریپارامترها یا مدیریت وضعیتهای خطا را پیادهسازی کند. در این درس، با مفاهیم پایهای API آشنا میشوید. دلایل استفاده از DRF به جای نوشتن دستی API بررسی میگردد. همچنین توضیح داده میشود که چرا جنگوی خالص به تنهایی گزینه مناسبی برای پیادهسازی API نیست. محتوای این درس جنبه تئوری دارد. اما تلاش شده هر مفهوم همراه با مثال عینی ارائه شود. هدف این است که پس از مطالعه این درس، بدانید دقیقاً DRF در چه مرحلهای از توسعه یک پروژه به کار میآید.
- نصب DRF در درس قبل فهمیدید DRF چیست و چه مشکلاتی از جنگوی خالص را حل میکند. حالا نوبت رسیده که دست به کد شوید. نصب drf اولین قدم عملی برای ساختن API با جنگو است. بدون این مرحله، هیچکدام از ابزارهایی که معرفی شد (سریالایزر، ویوست، احراز هویت آماده) در دسترس شما نخواهند بود. نصب خودش کار سادهای است. یک خط دستور در ترمینال. اما چند نکته ظریف دارد. مثلاً باید DRF را به INSTALLED_APPS اضافه کنید. در غیر اینصورت حتی اگر نصب شده باشد، جنگو آن را نمیبیند. همچنین بعضی کتابخانههای جانبی مثل django-filter و markdown اگر نباشند، بعضی قابلیتهای DRF کار نمیکنند. در این درس تک تک این موارد را میبینید. در انتهای درس، یک ویو تستی مینویسیم. با باز کردن آن در مرورگر، مطمئن میشوید نصب drf به درستی انجام شده و محیط شما آماده درسهای بعدی است.
- نوشتن اولین API با Function-Based View تا اینجا DRF را نصب کردهاید. تنظیمات اولیه را انجام دادهاید. حتی یک ویو تستی با APIView نوشتید و دیدید که Browsable API چطور کار میکند. اما آن ویو فقط یک پیام ساده برمیگرداند. بدون مدل، بدون دیتابیس، بدون هیچ منطق واقعی. وقتش رسیده که دستتان به کد واقعی API عادت کند. در این درس، با سادهترین روش ممکن یک API مینویسیم: Function-Based View. نیازی به کلاس پیچیده نیست. نیازی به سریالایزر هم نداریم. فقط یک تابع پایتونی با یک دکوریتور خاص. بعد از نوشتن API، یاد میگیرید چطور با Postman آن را تست کنید. Postman ابزاری است که هر توسعهدهنده بکاند باید بلد باشد. بدون آن، Testing APIها خستهکننده و وقتگیر میشود. در انتهای این درس، شما میتوانید: یک API با متد GET بنویسید پارامتر از مسیر (Dynamic URL) بگیرید Query Parameter دریافت کنید همه را با Postman تست کنید این درس پلی است بین مباحث تئوری و کار عملی واقعی. بعد از این درس، وارد بحث سریالایزرها میشویم. اما فعلاً تمرکز روی سادگی و درک جریان درخواست و پاسخ است. اگر محیط جنگو و DRF شما آماده است، بیایید شروع کنیم.
- سریالایز ها در DRF تا اینجا یاد گرفتید چطور یک ویو ساده با @api_view بنویسید. در آن ویوها، داده را دستی به دیکشنری تبدیل میکردیم. برای هر بار تبدیل، کد جداگانه مینوشتیم. این روش برای پروژههای کوچک شاید کار کند. اما وقتی مدل شما ۲۰ فیلد داشته باشد، نوشتن این کد تبدیل برای هر مدل تکراری و خستهکننده میشود. اینجا جایی است که سریالایزرها وارد میشوند. سریالایزر در DRF کاری شبیه همان فرمها در جنگوی معمولی انجام میدهد. داده مدل را میگیرد و به JSON تبدیل میکند. JSON دریافتی از کاربر را میگیرد، اعتبارسنجی میکند، و به مدل تبدیل مینماید. به همین دلیل به آن قلب DRF میگویند. بدون سریالایزر، هیچکدام از ویوهای پیشرفتهتر (کلاسبیس، جنریک، ویوست) کار نمیکنند. در این درس از صفر شروع میکنیم. اول با یک Serializer ساده کار میکنیم. بعد میبینیم ModelSerializer چطور کد ما را کوتاهتر میکند. در انتها یاد میگیرید چطور اعتبارسنجی سفارشی بنویسید و خروجی سریالایزر را تغییر دهید. اگر درسهای قبل را خوب متوجه شدهاید، برای این درس کاملاً آماده هستید. تنها چیزی که نیاز دارید یک مدل ساده است که همان اول درس میسازیم.
- کلاس بیس ویو ها در DRF تا الان دو روش برای نوشتن ویو در DRF امتحان کردهاید. اولی با @api_view دکوریتور روی توابع ساده. همان روشی که در درس های قبلی کار کردید. این روش برای چند خط کد و پروژههای کوچک، مناسب است. دومی با Serializerها که در درس قبل یاد گرفتید. حالا مدل دارید، Serializer دارید، اما ویوها هنوز تابعی هستند. اینجا یک مشکل ظاهر میشود. فرض کنید میخواهید پنج API مختلف بنویسید. هر کدام نیاز به منطق مشابهی دارند. مثلاً همه باید چک کنند کاربر لاگین کرده یا نه. یا همه باید خطاهای مشابهی برگردانند. با روش تابعی، مجبورید این کدهای تکراری را در هر تابع بنویسید. یا توابع کمکی بسازید و در جای دیگر صدا بزنید. کلاسبیس ویوها این مشکل را حل میکنند. APIView پایهترین کلاس در DRF است. با آن میتوانید متدهای GET، POST، PUT، DELETE را جداگانه در یک کلاس تعریف کنید. کد تمیزتر میشود. قابلیت استفاده مجدد بالا میرود. در این درس، یک CRUD کامل با APIView مینویسیم. یعنی چهار عمل اصلی: خواندن لیست، خواندن جزئیات، ساختن، بروزرسانی، و حذف. همچنین یاد میگیرید چطور داده را از request.data و request.query_params بخوانید. و چطور پاسخ را با Response برگردانید. اگر درس Serializerها را خوب متوجه شدهاید، این درس برای شما ساده خواهد بود. چون منطق اصلی همان است. فقط ساختار ویوها را از تابع به کلاس تغییر میدهیم.
- ویو های جنریک در DRF در درس قبل، با APIView یک CRUD کامل نوشتید. پنج متد مختلف. دو کلاس جداگانه. منطق پیدا کردن شیء را در سه جای مختلف تکرار کردید. کار میکرد. اما کد زیادی داشت. حالا فرض کنید بخواهید همین کار را برای مدل Product یا User هم بنویسید. دوباره همان کدهای تکراری را مینویسید. دوباره get_object میسازید. دوباره اعتبارسنجی دستی میکنید. اینجا جایی است که ویوهای جنریک وارد میشوند. ListCreateAPIView و RetrieveUpdateDestroyAPIView دو کلاس آماده در DRF هستند. خیلی از کارهایی که شما در APIView دستی نوشتید، اینها از قبل برایتان انجام میدهند. نیازی به نوشتن get_object نیست. نیازی به چک کردن ۴۰۴ نیست. نیازی به تکرار منطق در چند متد ندارید. در این درس، با همین دو کلاس، کل CRUD قبلی را در کمتر از ۱۰ خط کد بازنویسی میکنید. همچنین یاد میگیرید چطور با get_queryset و get_serializer_class رفتار پیشفرض را تغییر دهید. و در انتها با mixins آشنا میشوید؛ قطعات کوچکی که میتوانید آنها را ترکیب کنید و ویوهای سفارشی بسازید. اگر درس APIView را خوب درک کرده باشید، این درس برای شما مثل یک اتوماتیکسازی شیرین خواهد بود.
- ویو ست ها و روتر ها تا الان سه روش برای نوشتن ویو در DRF یاد گرفتهاید. روش اول: Function-Based View با دکوریتور @api_view. ساده اما برای پروژههای بزرگ کافی نیست. روش دوم: APIView. کنترل کامل روی منطق ویو. اما برای هر مدل باید چندین کلاس جداگانه بنویسید. روش سوم: Generic Views مثل ListCreateAPIView. کدها خیلی کوتاه شدند. اما همچنان برای هر مدل به دو کلاس مجزا نیاز دارید. یکی برای لیست و ساختن، دیگری برای جزئیات و بروزرسانی و حذف. حالا فرض کنید پروژه شما ده مدل داشته باشد. باید بیست کلاس بنویسید. هر کدام با مسیرهای جداگانه. اینجا ViewSet وارد میشود. یک ViewSet همه عملیاتهای CRUD را در یک کلاس جمع میکند. دیگر خبری از دو کلاس جداگانه نیست. فقط یک کلاس برای هر مدل. اما این همه ماجرا نیست. ViewSetها با Router همراه میشوند. دیگر نیازی نیست urlpatterns را دستی پر کنید. Router خودکار مسیرهای مربوط به هر عملیات را میسازد. در این درس، از ModelViewSet شروع میکنیم. سپس ReadOnlyModelViewSet را یاد میگیرید. بعد با DefaultRouter آشنا میشوید. در انتها هم یاد میگیرید چطور متدهای سفارشی مثل activate/ را با @action به ViewSet اضافه کنید. اگر Generic Views را خوب فهمیده باشید، ViewSet برای شما یک ارتقاء طبیعی و شیرین خواهد بود.