Summarize this content to 400 words in Persian Lang ممکن است نام REST و RESTful API و مواردی از این قبیل را شنیده باشید
“API شما باید REST را پیاده سازی کند”
“آیا API شما یک API REST است؟”
بنابراین احتمالاً این اصطلاح را زیاد شنیده‌اید، و احتمالاً شنیده‌اید که در واقع کمی از آن استفاده نادرست شده است.
بنابراین اجازه دهید در مورد آنچه که REST است صحبت کنیم
خوب “REST مجموعه ای از محدودیت های معماری است”، مانند
– درخواست ها از طریق HTTP مدیریت می شوند. بنابراین به عنوان مثال، شما نمی توانید یک سرویس REST داشته باشید که از پروتکل دیگری غیر از HTTP استفاده می کند.
– APIها یا REST APIها باید ارتباط کلاینت-سرور بدون حالت باشند، به این معنی که تماس دوم نمی تواند به برقراری تماس اول بستگی داشته باشد. بنابراین آنها باید تماس های مستقل باشند.
– بنابراین، شما باید بتوانید داده ها را در حافظه پنهان ذخیره کنید، نه اینکه هر بار به داده های جدید نیاز داشته باشید، ما نیز می توانیم این کار را انجام دهیم.
– باید یک رابط یکنواخت وجود داشته باشد. به این معنی که باید کاملاً واضح باشد که چگونه می‌توان داده‌ها را از API خود خارج کرد تا تقریباً شبیه به کد خود مستندسازی باشد. به راحتی می توان حدس زد که API در آینده چه کاری انجام خواهد داد.
غیر از این موارد ممنوعیت های بیشتری وجود دارد.
یک لیست کامل از آنها وجود دارد
چیزها سیستم لایه ای هستند و به طور بالقوه بر اساس تقاضا کد می کنند و خیلی چیزهای دیگر
اما بیایید در مورد اینکه واقعا REST چه بود صحبت کنیم؟ از کجا آمده است؟ و آیا مهم است؟
بنابراین، REST توسط روی فیلدینگ طراحی شد. و روی فیلدینگ کار دکترای خود را انجام می داد. و روی به REST رسید که در پایان نامه دکتری خود تعریف کرد. بنابراین، اگر با دکترا آشنایی دارید، یک دوره دکتری است. این یک فرآیند بسیار پیچیده، بسیار زمان بر و بسیار فنی برای تشخیص اینکه شما یک موضوع را به خوبی می دانید است.
و بنابراین پایان نامه او در مورد سبک های معماری و طراحی معماری نرم افزار مبتنی بر شبکه بود. بنابراین همه چیز واقعا پیچیده است. و در آنجا ساختار REST را تعریف کرد.
حال، اگر واقعاً به پایان نامه اصلی و آنچه در پایان نامه اصلی درباره نحوه طراحی REST گفته شده است نگاه کنید، متوجه خواهید شد که تقریباً هیچ API امروزه REST را به طور کامل پیاده سازی نمی کند. چیزهای زیادی برای REST وجود دارد، و از بسیاری جهات بسیار تئوری است.
بنابراین این توصیه من به شماست که باید آن را درمان کنیدREST به عنوان یک توصیه طراحی.”
شما نباید نگران باشید که همه چیز کاملاً آرام باشد. در غیر این صورت، اتفاقی که می افتد این است که شما شروع به ساخت یک API می کنید که واقعاً خوب کار نمی کند.
شما باید ساخت یک API را بر اساس یک استاندارد شروع کنید نه بر اساس آنچه که برای API شما بهترین است.
و بله، یک تعادل وجود دارد. اما مانند هر چیز دیگری، اعم از یک الگوی طراحی، عمل طراحی، یا اصل، باید مطمئن شوید که انتخاب مناسبی برای برنامه خود دارید، نه اینکه مطمئن شوید که برنامه شما کاملاً از یک “قانون” پیروی می کند. زیرا REST یک قانون است. نیازی به داشتن API نیست که دقیقاً از REST پیروی کند.
و اگر این نیاز را دارید، ایجاد API شما دشوار خواهد بود.
شما باید مطمئن شوید که برنامه شما RESTful است. پیروی از روح قانون است. بنابراین این بدان معناست که شما افعال استاندارد HTTP دارید.
بنابراین، GET یک فعل است، و آن برای دریافت داده است. POST، و این برای ایجاد داده است. و سپس PUT یا PATCH را داریم که برای به روز رسانی داده ها استفاده می شود. و حذف داریم که برای حذف داده ها استفاده می شود.
و شما باید به جای سوء استفاده از سیستم از آن افعال به درستی استفاده کنید.
زیرا می توانید یک API ایجاد کنید که از POST برای همه چیز استفاده می کند. برای ایجاد، به‌روزرسانی و حذف، و کاملاً کار می‌کند، اما از روح REST پیروی نمی‌کند.
چون نمی دانی، چرا این کار را در مقابل آن راه انجام دهیم؟ چرا از POST برای همه چیز استفاده می کردید؟
این طراحی عالی نیست.
بنابراین باید در مورد استفاده از افعال مختلف HTTP شفاف باشید.
شما همچنین نامگذاری ثابتی خواهید داشت، بنابراین برای مثال، باید کاربرانی ایجاد کنید. بنابراین شما گزینه های CRUD را روی کاربران دارید، به عنوان مثال، ایجاد، خواندن، به روز رسانی و حذف. نام همه آنها /users خواهد بود، زیرا هنگام ارسال پست، یک کاربر ایجاد می کنید، و زمانی که حذف می کنید، یک کاربر را حذف می کنید. و بنابراین به جای داشتن نقطه پایانی که می گوید “حذف-کاربر” و یک نقطه پایانی متفاوت که “ایجاد کاربر” است، زیرا درک آن کمی سخت تر است و سازگار نیست.
بنابراین شما ساختار نامگذاری خوبی برای APIها دارید تا کارها را به خوبی انجام دهید.
*در نهایت، با تکرار دوباره، REST را به عنوان یک توصیه طراحی، مانند یک اصل طراحی که باید دنبال کنید، به جای یک قانون سخت و سریع، در نظر بگیرید.
*
اگر نظر یا پیشنهادی دارید لطفاً در بخش نظرات به من اطلاع دهید یا به من ایمیل بزنید @ icodemechanic@gmail.com
ممکن است نام REST و RESTful API و مواردی از این قبیل را شنیده باشید
“API شما باید REST را پیاده سازی کند”
“آیا API شما یک API REST است؟”
بنابراین احتمالاً این اصطلاح را زیاد شنیده‌اید، و احتمالاً شنیده‌اید که در واقع کمی از آن استفاده نادرست شده است.
بنابراین اجازه دهید در مورد آنچه که REST است صحبت کنیم
خوب “REST مجموعه ای از محدودیت های معماری است“، مانند
– درخواست ها از طریق HTTP مدیریت می شوند. بنابراین به عنوان مثال، شما نمی توانید یک سرویس REST داشته باشید که از پروتکل دیگری غیر از HTTP استفاده می کند.
– APIها یا REST APIها باید ارتباط کلاینت-سرور بدون حالت باشند، به این معنی که تماس دوم نمی تواند به برقراری تماس اول بستگی داشته باشد. بنابراین آنها باید تماس های مستقل باشند.
– بنابراین، شما باید بتوانید داده ها را در حافظه پنهان ذخیره کنید، نه اینکه هر بار به داده های جدید نیاز داشته باشید، ما نیز می توانیم این کار را انجام دهیم.
– باید یک رابط یکنواخت وجود داشته باشد. به این معنی که باید کاملاً واضح باشد که چگونه می‌توان داده‌ها را از API خود خارج کرد تا تقریباً شبیه به کد خود مستندسازی باشد. به راحتی می توان حدس زد که API در آینده چه کاری انجام خواهد داد.
غیر از این موارد ممنوعیت های بیشتری وجود دارد.
یک لیست کامل از آنها وجود دارد
چیزها سیستم لایه ای هستند و به طور بالقوه بر اساس تقاضا کد می کنند و خیلی چیزهای دیگر
اما بیایید در مورد اینکه واقعا REST چه بود صحبت کنیم؟ از کجا آمده است؟ و آیا مهم است؟
بنابراین، REST توسط روی فیلدینگ طراحی شد. و روی فیلدینگ کار دکترای خود را انجام می داد. و روی به REST رسید که در پایان نامه دکتری خود تعریف کرد. بنابراین، اگر با دکترا آشنایی دارید، یک دوره دکتری است. این یک فرآیند بسیار پیچیده، بسیار زمان بر و بسیار فنی برای تشخیص اینکه شما یک موضوع را به خوبی می دانید است.
و بنابراین پایان نامه او در مورد سبک های معماری و طراحی معماری نرم افزار مبتنی بر شبکه بود. بنابراین همه چیز واقعا پیچیده است. و در آنجا ساختار REST را تعریف کرد.
حال، اگر واقعاً به پایان نامه اصلی و آنچه در پایان نامه اصلی درباره نحوه طراحی REST گفته شده است نگاه کنید، متوجه خواهید شد که تقریباً هیچ API امروزه REST را به طور کامل پیاده سازی نمی کند. چیزهای زیادی برای REST وجود دارد، و از بسیاری جهات بسیار تئوری است.
بنابراین این توصیه من به شماست که باید آن را درمان کنیدREST به عنوان یک توصیه طراحی.“
شما نباید نگران باشید که همه چیز کاملاً آرام باشد. در غیر این صورت، اتفاقی که می افتد این است که شما شروع به ساخت یک API می کنید که واقعاً خوب کار نمی کند.
شما باید ساخت یک API را بر اساس یک استاندارد شروع کنید نه بر اساس آنچه که برای API شما بهترین است.
و بله، یک تعادل وجود دارد. اما مانند هر چیز دیگری، اعم از یک الگوی طراحی، عمل طراحی، یا اصل، باید مطمئن شوید که انتخاب مناسبی برای برنامه خود دارید، نه اینکه مطمئن شوید که برنامه شما کاملاً از یک “قانون” پیروی می کند. زیرا REST یک قانون است. نیازی به داشتن API نیست که دقیقاً از REST پیروی کند.
و اگر این نیاز را دارید، ایجاد API شما دشوار خواهد بود.
شما باید مطمئن شوید که برنامه شما RESTful است. پیروی از روح قانون است. بنابراین این بدان معناست که شما افعال استاندارد HTTP دارید.
بنابراین، GET یک فعل است، و آن برای دریافت داده است. POST، و این برای ایجاد داده است. و سپس PUT یا PATCH را داریم که برای به روز رسانی داده ها استفاده می شود. و حذف داریم که برای حذف داده ها استفاده می شود.
و شما باید به جای سوء استفاده از سیستم از آن افعال به درستی استفاده کنید.
زیرا می توانید یک API ایجاد کنید که از POST برای همه چیز استفاده می کند. برای ایجاد، به‌روزرسانی و حذف، و کاملاً کار می‌کند، اما از روح REST پیروی نمی‌کند.
چون نمی دانی، چرا این کار را در مقابل آن راه انجام دهیم؟ چرا از POST برای همه چیز استفاده می کردید؟
این طراحی عالی نیست.
بنابراین باید در مورد استفاده از افعال مختلف HTTP شفاف باشید.
شما همچنین نامگذاری ثابتی خواهید داشت، بنابراین برای مثال، باید کاربرانی ایجاد کنید. بنابراین شما گزینه های CRUD را روی کاربران دارید، به عنوان مثال، ایجاد، خواندن، به روز رسانی و حذف. نام همه آنها /users خواهد بود، زیرا هنگام ارسال پست، یک کاربر ایجاد می کنید، و زمانی که حذف می کنید، یک کاربر را حذف می کنید. و بنابراین به جای داشتن نقطه پایانی که می گوید “حذف-کاربر” و یک نقطه پایانی متفاوت که “ایجاد کاربر” است، زیرا درک آن کمی سخت تر است و سازگار نیست.
بنابراین شما ساختار نامگذاری خوبی برای APIها دارید تا کارها را به خوبی انجام دهید.
*در نهایت، با تکرار دوباره، REST را به عنوان یک توصیه طراحی، مانند یک اصل طراحی که باید دنبال کنید، به جای یک قانون سخت و سریع، در نظر بگیرید.
*
اگر نظر یا پیشنهادی دارید لطفاً در بخش نظرات به من اطلاع دهید یا به من ایمیل بزنید @ icodemechanic@gmail.com
