Forwarded from Code Module | کد ماژول (Mahan-Heydari)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Gopher Academy
🔵 عنوان مقاله
Go Performance from Version 1.0 to 1.22
🟢 خلاصه مقاله:
مقالهای که به بررسی تحلیلی عملکرد زبان برنامهنویسی Go از نسخه ۱.۰ تا آخرین نسخه یعنی ۱.۲۲ میپردازد، ادامهای است بر تحلیلهای قبلی نویسنده از نسخههای ۱.۲ تا ۱.۱۸ که دو سال پیش منتشر شده بود. در این مقاله، تحولات و بهینهسازیهای صورت گرفته در عملکرد زبان Go طی این سالها از ابتدای تولید تا به امروز بررسی شده است. نویسنده با استفاده از دادهها و شواهد محکم، تغییرات کلیدی در معماری و عملکرد زبان را به تفصیل تشریح کرده و نشان میدهد که چگونه این تحولات به افزایش کارایی و بهرهوری در برنامهنویسی کمک کردهاند. این مقاله میتواند منبع مفیدی برای توسعهدهندگان و مهندسان نرمافزار باشد که میخواهند دیدگاه عمیقتری نسبت به تکامل زبان Go و عملکرد آن داشته باشند.
🟣لینک مقاله:
https://benhoyt.com/writings/go-version-performance-2024/
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Go Performance from Version 1.0 to 1.22
🟢 خلاصه مقاله:
مقالهای که به بررسی تحلیلی عملکرد زبان برنامهنویسی Go از نسخه ۱.۰ تا آخرین نسخه یعنی ۱.۲۲ میپردازد، ادامهای است بر تحلیلهای قبلی نویسنده از نسخههای ۱.۲ تا ۱.۱۸ که دو سال پیش منتشر شده بود. در این مقاله، تحولات و بهینهسازیهای صورت گرفته در عملکرد زبان Go طی این سالها از ابتدای تولید تا به امروز بررسی شده است. نویسنده با استفاده از دادهها و شواهد محکم، تغییرات کلیدی در معماری و عملکرد زبان را به تفصیل تشریح کرده و نشان میدهد که چگونه این تحولات به افزایش کارایی و بهرهوری در برنامهنویسی کمک کردهاند. این مقاله میتواند منبع مفیدی برای توسعهدهندگان و مهندسان نرمافزار باشد که میخواهند دیدگاه عمیقتری نسبت به تکامل زبان Go و عملکرد آن داشته باشند.
🟣لینک مقاله:
https://benhoyt.com/writings/go-version-performance-2024/
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Benhoyt
Go performance from version 1.0 to 1.22
Shows how much the performance of Go has improved from version 1.0 through to 1.22 (including PGO) -- in its compiler, runtime, and libraries.
Forwarded from کداکسپلور | CodeExplore (Koorosh)
جاوااسکریپت چطوری خلق شد؟ ✌️
📌 یه نکته جالب درباره جاوااسکریپت که خیلیها نمیدونن اینه که جاوااسکریپت در اصل در ۱۰ روز توسط یک برنامهنویس به نام برندان آیک ساخته شد! اون زمان شرکت Netscape به سرعت به یه زبان اسکریپتنویسی برای وب نیاز داشت تا بتونه با رقبا رقابت کنه. این زبان اول به نام Mocha معرفی شد، بعد اسمش شد LiveScript و نهایتاً برای استفاده از شهرت جاوا، اسمش رو به جاوااسکریپت تغییر دادن، با اینکه ارتباط زیادی با جاوا نداره.
💥 در واقع، جاوااسکریپت خیلی سریع طراحی شد و انتظار نمیرفت که تبدیل به یکی از مهمترین زبانهای وب بشه!
#javanoscript #js
☕️ @CodeExplore
#javanoscript #js
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from کانال مهرداد لینوکس (Mehrdad Linux)
Forwarded from Go Casts 🚀
سراب دنیای نرم افزاری
برای خودم زیاد پیش میاد که دچار هیجان مثبت و منفی بیش از حد بشم در مورد یه چیزی حین کار.
این هیجان میتونه در مورد یه ایده جدید باشه، در مورد یادگیری یه موضوع جدید باشه، یا حتی استرس یه incident و باگ باشه.
خیلی اوقات دوست دارم تا بی نهایت وقت داشته باشم که روی یک محصول نرم افزاری کار کنم ولی از اینکه چنین وقتی ندارم ناامید میشم.
بعضی وقت ها هم که خیلی غرق کار میشم یهو از درون خالی میشم و دچار پوچی میشم، حس بیهوده بودن میکنم، اینکه اصلا چرا دارم این کار رو میکنم، آینده ش چی میشه و غیره
چنین حس هایی ممکنه کم و بیش سراغ خیلی ها اومده باشه
نسخه ای که سعی میکنم برای خودم بپیچم اینه که سعی کنم از هیچ چیزی رویا نسازم، توهم فانتزی و خیالی نداشته باشم در مورد ساخت محصول خاصی یا موقعیت خاصی
این نسخه ممکنه گاها باعث دلسردی هم بشه، اما برای من حداقل فکر میکنم منفعت هاش بیشتر از مضراتش هست، چون بهم کمک میکنه یه تعادلی بین کار و زندگی ایجاد کنم، نه کار رو اونقدر شیرین و جذاب ببینم که زمان هایی که کار نمیکنم افسوس بخورم، و نه اونقدر کار رو سخت و پر استرس ببینم که نخوام سمت ش برم، داشتن دید واقع بینانه نسبت به حال و آینده کار در حد توان(طبیعتا خیلی چیزهای آینده رو نمیشه پیش بینی کرد)، فکر میکنم باعث بشه سطح انتظارمون رو بهتر تشخیص بدیم و از کاری که میکنیم به طور میانگین بیشتر لذت ببریم و کمتر حسرت کارهای انجام نداده رو بخوریم.
دو سه روز پیش این مصاحبه از آقای اسمش رو نبر (اینقدر که تلفظش سخته!) دیدم، سازنده زبان سی پلاس پلاس، که توصیه های جالبی داشتند که کم و بیش مرتبطه به این موضوع، دوست داشتید ببینید
https://www.youtube.com/watch?v=-QxI-RP6-HM
@gocasts
برای خودم زیاد پیش میاد که دچار هیجان مثبت و منفی بیش از حد بشم در مورد یه چیزی حین کار.
این هیجان میتونه در مورد یه ایده جدید باشه، در مورد یادگیری یه موضوع جدید باشه، یا حتی استرس یه incident و باگ باشه.
خیلی اوقات دوست دارم تا بی نهایت وقت داشته باشم که روی یک محصول نرم افزاری کار کنم ولی از اینکه چنین وقتی ندارم ناامید میشم.
بعضی وقت ها هم که خیلی غرق کار میشم یهو از درون خالی میشم و دچار پوچی میشم، حس بیهوده بودن میکنم، اینکه اصلا چرا دارم این کار رو میکنم، آینده ش چی میشه و غیره
چنین حس هایی ممکنه کم و بیش سراغ خیلی ها اومده باشه
نسخه ای که سعی میکنم برای خودم بپیچم اینه که سعی کنم از هیچ چیزی رویا نسازم، توهم فانتزی و خیالی نداشته باشم در مورد ساخت محصول خاصی یا موقعیت خاصی
این نسخه ممکنه گاها باعث دلسردی هم بشه، اما برای من حداقل فکر میکنم منفعت هاش بیشتر از مضراتش هست، چون بهم کمک میکنه یه تعادلی بین کار و زندگی ایجاد کنم، نه کار رو اونقدر شیرین و جذاب ببینم که زمان هایی که کار نمیکنم افسوس بخورم، و نه اونقدر کار رو سخت و پر استرس ببینم که نخوام سمت ش برم، داشتن دید واقع بینانه نسبت به حال و آینده کار در حد توان(طبیعتا خیلی چیزهای آینده رو نمیشه پیش بینی کرد)، فکر میکنم باعث بشه سطح انتظارمون رو بهتر تشخیص بدیم و از کاری که میکنیم به طور میانگین بیشتر لذت ببریم و کمتر حسرت کارهای انجام نداده رو بخوریم.
دو سه روز پیش این مصاحبه از آقای اسمش رو نبر (اینقدر که تلفظش سخته!) دیدم، سازنده زبان سی پلاس پلاس، که توصیه های جالبی داشتند که کم و بیش مرتبطه به این موضوع، دوست داشتید ببینید
https://www.youtube.com/watch?v=-QxI-RP6-HM
@gocasts
YouTube
(Life) Advice From The Creator of C++
The creator of C++, Bjarne Stroustrup, shares some valuable life advice that, let’s face it, all developers, no matter their years of experience could use. According to Bjarne, ‘You can’t just do code’, you need to develop more skills if you want to be a…
Forwarded from کداکسپلور | CodeExplore (𝙰𝚖𝚒𝚗)
#api #github
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - toddmotto/public-apis: A collective list of free APIs
A collective list of free APIs. Contribute to toddmotto/public-apis development by creating an account on GitHub.
Forwarded from جادی | Jadi
این دفعه در حل سوالات مصاحبه کاری به یه سوال بامزه و راحت و سر راست برخوردیم؛ شانس داشتیم: یه رشته کاراکتری رو گرفتین (شبیه یه جمله) و باید طول آخرین کلمهای که توش هست رو برگردونین. چون ساده و سر راست است با سی می نویسیم (:
https://youtu.be/FKbN477bdxM
https://youtu.be/FKbN477bdxM
YouTube
سوالات الگوریتمی برای فان و مصاحبه: طول آخرین کلمه در یک جمله
هوم. این به نظر سر راست میاد: یک رشته (عبارت متنی) بگیرین و طول آخرین کلمهای که توش هست رو برگردونین. چون آسونه با سی می نویسیم (: البته گار درست یادم باشه.
https://leetcode.com/problems/length-of-last-word/
به حامیان کانال بپیوندین (:
https://www.yo…
https://leetcode.com/problems/length-of-last-word/
به حامیان کانال بپیوندین (:
https://www.yo…
Forwarded from Agora (Alireza Azadi)
این رشته توییت جالب از سرگذشت «یک میلیون چکباکس» رو از دست ندین:
https://x.com/Loc0m0/status/1832188628719825347
خود ماجرا رو هم میتونید از زبون خود سازنده، تو یوتیوب ببینید که بامزهس:
https://youtu.be/OI4DbECnp8A?si=T3Y0PLuPrZMFNCBh
https://x.com/Loc0m0/status/1832188628719825347
خود ماجرا رو هم میتونید از زبون خود سازنده، تو یوتیوب ببینید که بامزهس:
https://youtu.be/OI4DbECnp8A?si=T3Y0PLuPrZMFNCBh
YouTube
The Secret Inside One Million Checkboxes
My favorite story from One Million Checkboxes (https://onemillioncheckboxes.com) - a website of mine that became shockingly popular. It begins with me thinking I was hacked and ends with my crying some (very proud) tears due to some very talented teens.
…
…
Forwarded from محتوای آزاد سهراب
Forwarded from Linuxor ?
این یه SD Card ساده نیست یه کامپیوتر که یه ماژول Wi-Fi داره و یه لینوکس کوچولو برای اشتراک گذاری دیتا ها از طریق Wi-Fi.
به این صورته که مثلا به دوربین عکاسیتون وصلش میکنید و اگه با دوربین عکس یا فیلم بگیرید توی این SD Card ذخیره میشه و اگه با گوشیتون به Wi-Fi ش وصل شید داخل مروگر گوشیتون روی یه Ip خاص که بهتون میده میتونید فایل های ایجاد شده داخل SD Card رو بی سیم دانلود و مدیریت کنید.
🐧 @Linuxor ~ photo : QVHankel
به این صورته که مثلا به دوربین عکاسیتون وصلش میکنید و اگه با دوربین عکس یا فیلم بگیرید توی این SD Card ذخیره میشه و اگه با گوشیتون به Wi-Fi ش وصل شید داخل مروگر گوشیتون روی یه Ip خاص که بهتون میده میتونید فایل های ایجاد شده داخل SD Card رو بی سیم دانلود و مدیریت کنید.
🐧 @Linuxor ~ photo : QVHankel
Forwarded from کداکسپلور | CodeExplore (R.Po)
تو ریپازیتوری گیتهاب زیر میتونین اصطلاحات Functional Programming رو یاد بگیرید ( این سایت رو واسه دوستانی معرفی کردم که اصطلاحات برنامه نویسی رو نمی دونن )
🌐 http://git.io/fp-jargons
#پست_پیشنهادی
#programming #expression
☕️ @CodeExplore
#پست_پیشنهادی
#programming #expression
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from چنل شخصی سید رحیم فیروزی
سلام
سایت aixploria یک لیست عالی از ابزار های هوش مصنوعی (AI) هست که به شما کمک می کنند ، ابزار مورد نیاز خودتان را پیدا و استفاده کنید
https://www.aixploria.com/en/
پس برید و از استفاده از این ابزار لذت ببرید
موفق باشید 🌹
@srfirouzi_channel
سایت aixploria یک لیست عالی از ابزار های هوش مصنوعی (AI) هست که به شما کمک می کنند ، ابزار مورد نیاز خودتان را پیدا و استفاده کنید
https://www.aixploria.com/en/
پس برید و از استفاده از این ابزار لذت ببرید
موفق باشید 🌹
@srfirouzi_channel
AIxploria
AI Tools Directory & List of Best Free AI by Category (Top 10) | AIxploria
Access Aixploria, an AI tools directory featuring the largest list of AI available on the net. A ranking of the best AI to help you in your search.
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل دوم: Identifier Design with URIs
📍پارت: دوم
#کتاب
💎 URI Authority Design 💎
این بخش به نامگذاریهایی که باید برای قسمت "authority" (یا همان بخش اصلی آدرس) یک REST API استفاده شود، میپردازد.
⭕️ برای API هاتون باید از نامهای زیردامنهای منظم و یکسان استفاده کنید.
دامنه اصلی و اولین زیردامنه (مثلاً soccer.restapi.org) باید مشخصکننده مالک سرویس باشه. کل نام دامنه یک API باید یک زیردامنه به نام api اضافه کنه. برای مثال:
⭕️ برای پرتال توسعه دهندگان API هاتون باید از نامهای زیردامنهای منظم و یکسان استفاده کنید. خیلی از REST API ها یک وبسایت دارند که به عنوان پرتال توسعهدهندگان شناخته میشه و به کمک مستندات، انجمنها و ارائه کلیدهای دسترسی امن به API، کاربران جدید رو راهنمایی میکنه. اگر API شما یک پرتال توسعهدهنده داره، طبق عرف باید زیردامنهای به نام developer داشته باشه. برای مثال:
💎 Resource Modeling 💎
مسیر URI مدل منابع یک REST API رو نشون میده، به این صورت که هر بخش از مسیر که با اسلش جدا شده، به یک منبع منحصر به فرد در سلسله مراتب مدل اشاره میکنه. برای مثال، این طراحی URI:
نشون میده که هر کدوم از این URIها هم باید به یک منبع آدرسپذیر اشاره کنند:
مدلسازی منابع فرآیندیه که مفاهیم کلیدی API شما رو مشخص میکنه. این فرآیند شبیه مدلسازی داده برای یک پایگاه داده رابطهای یا مدلسازی کلاسیک در سیستمهای شیگرا است.
قبل از اینکه مستقیم وارد طراحی مسیرهای URI بشید، شاید بهتر باشه اول به مدل منابع REST API فکر کنید.
💎 Resource Archetypes 💎
هنگام مدلسازی منابع یک API، میتونیم با چند الگوی پایهای منابع شروع کنیم. مثل الگوهای طراحی، این الگوها به ما کمک میکنن که ساختارها و رفتارهای رایجی که در طراحی REST APIها وجود دارن رو به صورت منسجم بیان کنیم. یک REST API از چهار الگوی منبع مجزا تشکیل شده: سند (document)، مجموعه (collection)، فروشگاه (store)، و کنترلر (controller).
برای اینکه یک مدل منابع شفاف و ساده به مشتریان API منتقل بشه، یک REST API باید هر منبع رو فقط با یکی از این الگوها تطبیق بده. برای حفظ یکنواختی، وسوسه طراحی منابعی که ترکیبی از چند الگو هستن رو کنار بذارید. به جای این کار، بهتره منابع جداگانهای طراحی کنید که به صورت سلسلهمراتبی و/یا از طریق لینکها به هم مرتبط هستن، همونطور که در فصل ۵ توضیح داده شده.
هر کدوم از این الگوهای منبع در زیرمجموعههای بعدی به تفصیل توضیح داده شده.
@ninja_learn_ir
📌 فصل دوم: Identifier Design with URIs
📍پارت: دوم
#کتاب
💎 URI Authority Design 💎
این بخش به نامگذاریهایی که باید برای قسمت "authority" (یا همان بخش اصلی آدرس) یک REST API استفاده شود، میپردازد.
⭕️ برای API هاتون باید از نامهای زیردامنهای منظم و یکسان استفاده کنید.
دامنه اصلی و اولین زیردامنه (مثلاً soccer.restapi.org) باید مشخصکننده مالک سرویس باشه. کل نام دامنه یک API باید یک زیردامنه به نام api اضافه کنه. برای مثال:
http://api.soccer.restapi.org
⭕️ برای پرتال توسعه دهندگان API هاتون باید از نامهای زیردامنهای منظم و یکسان استفاده کنید. خیلی از REST API ها یک وبسایت دارند که به عنوان پرتال توسعهدهندگان شناخته میشه و به کمک مستندات، انجمنها و ارائه کلیدهای دسترسی امن به API، کاربران جدید رو راهنمایی میکنه. اگر API شما یک پرتال توسعهدهنده داره، طبق عرف باید زیردامنهای به نام developer داشته باشه. برای مثال:
http://developer.soccer.restapi.org
💎 Resource Modeling 💎
مسیر URI مدل منابع یک REST API رو نشون میده، به این صورت که هر بخش از مسیر که با اسلش جدا شده، به یک منبع منحصر به فرد در سلسله مراتب مدل اشاره میکنه. برای مثال، این طراحی URI:
http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet
نشون میده که هر کدوم از این URIها هم باید به یک منبع آدرسپذیر اشاره کنند:
http://api.soccer.restapi.org/leagues/seattle/teams
http://api.soccer.restapi.org/leagues/seattle
http://api.soccer.restapi.org/leagues
http://api.soccer.restapi.org
مدلسازی منابع فرآیندیه که مفاهیم کلیدی API شما رو مشخص میکنه. این فرآیند شبیه مدلسازی داده برای یک پایگاه داده رابطهای یا مدلسازی کلاسیک در سیستمهای شیگرا است.
قبل از اینکه مستقیم وارد طراحی مسیرهای URI بشید، شاید بهتر باشه اول به مدل منابع REST API فکر کنید.
💎 Resource Archetypes 💎
هنگام مدلسازی منابع یک API، میتونیم با چند الگوی پایهای منابع شروع کنیم. مثل الگوهای طراحی، این الگوها به ما کمک میکنن که ساختارها و رفتارهای رایجی که در طراحی REST APIها وجود دارن رو به صورت منسجم بیان کنیم. یک REST API از چهار الگوی منبع مجزا تشکیل شده: سند (document)، مجموعه (collection)، فروشگاه (store)، و کنترلر (controller).
برای اینکه یک مدل منابع شفاف و ساده به مشتریان API منتقل بشه، یک REST API باید هر منبع رو فقط با یکی از این الگوها تطبیق بده. برای حفظ یکنواختی، وسوسه طراحی منابعی که ترکیبی از چند الگو هستن رو کنار بذارید. به جای این کار، بهتره منابع جداگانهای طراحی کنید که به صورت سلسلهمراتبی و/یا از طریق لینکها به هم مرتبط هستن، همونطور که در فصل ۵ توضیح داده شده.
هر کدوم از این الگوهای منبع در زیرمجموعههای بعدی به تفصیل توضیح داده شده.
@ninja_learn_ir
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل دوم: Identifier Design with URIs
📍پارت: اول
#کتاب
💎 URIs 💎
توی وب API های REST از شناسههای منبع یکنواخت (URIs) برای آدرسدهی منابع استفاده میکنند.
امروزه، طراحیهای URI میتونن از شاهکارهایی باشن که مدل منبع API رو به وضوح نشون میدن،
مثل:
تا اونهایی که خیلی سختتر برای مردم قابل فهم هستن، مثل:
تیم برنرز-لی یه نکتهای درباره شفافیت URIs توی لیست "اصول معماری وب"ش ذکر کرده:
همونطور که توی فصل ۵ بحث شد، مشتریها باید از الگوی لینکدهی وب پیروی کنن و URIs رو به عنوان شناسههای غیرشفاف در نظر بگیرن. با این حال، طراحان APIهای REST باید URIsی طراحی کنن که مدل منبع API رو به وضوح به توسعهدهندگان احتمالی نشون بده.
این فصل یه سری قوانین طراحی برای URIs در APIهای REST رو معرفی میکنه.
💎 URI Format 💎
قوانینی که در این بخش ارائه شدهاند مربوط به فرمت یک URI هستند. استاندارد RFC 3986* سینتکس کلی URI رو به این شکل تعریف میکنه:
scheme: پروتکل یا روشی که برای دسترسی به منبع استفاده میشه، مثل http یا https.
authority: شامل اطلاعاتی مثل دامنه (domain) یا آدرس IP، و پورت سرور.
path: مسیر یا آدرسی که منبع خاصی رو در سرور مشخص میکنه.
query: پارامترهای اضافی که برای جستجو یا فیلتر کردن دادهها به URI اضافه میشن.
fragment: قسمتی از URI که به بخش خاصی از منبع اشاره میکنه، مثل یک بخش خاص از یک صفحه وب.
این قالب کلی به ما کمک میکنه تا ساختار URIها رو بهتر درک کنیم و بر اساس اونها، URIهایی طراحی کنیم که هم برای انسانها قابل فهم باشن و هم با استانداردهای وب سازگار باشن.
⭕️ از جداکنندهی اسلش (/) برای نشان دادن رابطهی سلسلهمراتبی استفاده کنید.
کاراکتر اسلش (/) در بخش مسیر (path) یک URI برای نشان دادن رابطهی سلسلهمراتبی بین منابع استفاده میشه. به عنوان مثال:
فرض کنید یک سایت دارید که شامل کشورها و شهرهاست. در این حالت، URI شما میتونه به این شکل باشه:
در این مثال، "iran" زیرمجموعهای از "countries" و "tehran" زیرمجموعهای از "iran" هست، که با استفاده از اسلش (/) این ساختار سلسلهمراتبی نشون داده شده.
این کار کمک میکنه تا URIها به شکلی ساختاریافته و قابل درک برای کاربران و توسعهدهندگان باشند.
⭕️ نباید از اسلش (/) درآخر URI ها استفاده کنید
وقتی اسلش (/) به عنوان آخرین کاراکتر در مسیر (path) یک URI قرار میگیره، هیچ ارزش معنایی اضافهای نداره و ممکنه باعث سردرگمی بشه. بنابراین، REST APIها نباید انتظار داشته باشند که URIها با یک اسلش انتهایی تموم بشند و نباید این نوع لینکها رو به کاربران ارائه بدهند.
بسیاری از اجزای وب و فریمورکها، این دو URI رو به طور یکسان در نظر میگیرند:
اما واقعیت اینه که هر کاراکتر در یک URI به شناسایی منحصر به فرد اون منبع کمک میکنه. دو URI متفاوت به دو منبع متفاوت اشاره میکنند. بنابراین، یک REST API باید URIهای تمیز و دقیق تولید کنه و نباید تلاشهای کاربران برای شناسایی منابع به شکل نادرست رو بپذیره.
البته، APIهای منعطفتر ممکنه کاربران رو به URIهایی بدون اسلش انتهایی هدایت کنند (همونطور که در قانون مربوط به استفاده از کد وضعیت 301 "Moved Permanently" برای جابجایی منابع توضیح داده شده).
⭕️ برای بهبود خوانایی URIها از خط تیره (-) استفاده کنید
برای اینکه URIهاتون رو برای افراد قابل فهم و قابل اسکن کنید، از کاراکتر خط تیره (-) استفاده کنید تا خوانایی نامها در بخشهای طولانی مسیر (path) بهتر بشه. هر جایی که در زبان انگلیسی از فاصله یا خط تیره استفاده میکنید، در URI هم باید از خط تیره استفاده کنید. به عنوان مثال:
این کار باعث میشه که URIها هم از نظر ظاهری بهتر و هم از نظر فهم و کاربرد راحتتر بشند.
📌 فصل دوم: Identifier Design with URIs
📍پارت: اول
#کتاب
💎 URIs 💎
توی وب API های REST از شناسههای منبع یکنواخت (URIs) برای آدرسدهی منابع استفاده میکنند.
امروزه، طراحیهای URI میتونن از شاهکارهایی باشن که مدل منبع API رو به وضوح نشون میدن،
مثل:
http://api.example.restapi.org/france/paris/louvre/leonardo-da-vinci/mona-lisa
تا اونهایی که خیلی سختتر برای مردم قابل فهم هستن، مثل:
http://api.example.restapi.org/68dd0-a9d3-11e0-9f1c-0800200c9a66
تیم برنرز-لی یه نکتهای درباره شفافیت URIs توی لیست "اصول معماری وب"ش ذکر کرده:
تنها چیزی که میتونید از یه شناسه استفاده کنید اینه که به یه شیء ارجاع بدید. وقتی که نمیخواید ارجاع بدید، نباید به محتوای رشته URI نگاه کنید تا اطلاعات دیگهای به دست بیارید.
همونطور که توی فصل ۵ بحث شد، مشتریها باید از الگوی لینکدهی وب پیروی کنن و URIs رو به عنوان شناسههای غیرشفاف در نظر بگیرن. با این حال، طراحان APIهای REST باید URIsی طراحی کنن که مدل منبع API رو به وضوح به توسعهدهندگان احتمالی نشون بده.
این فصل یه سری قوانین طراحی برای URIs در APIهای REST رو معرفی میکنه.
💎 URI Format 💎
قوانینی که در این بخش ارائه شدهاند مربوط به فرمت یک URI هستند. استاندارد RFC 3986* سینتکس کلی URI رو به این شکل تعریف میکنه:
URI = scheme "://" authority "/" path [ "?" query ] [ "#" fragment ]
scheme: پروتکل یا روشی که برای دسترسی به منبع استفاده میشه، مثل http یا https.
authority: شامل اطلاعاتی مثل دامنه (domain) یا آدرس IP، و پورت سرور.
path: مسیر یا آدرسی که منبع خاصی رو در سرور مشخص میکنه.
query: پارامترهای اضافی که برای جستجو یا فیلتر کردن دادهها به URI اضافه میشن.
fragment: قسمتی از URI که به بخش خاصی از منبع اشاره میکنه، مثل یک بخش خاص از یک صفحه وب.
این قالب کلی به ما کمک میکنه تا ساختار URIها رو بهتر درک کنیم و بر اساس اونها، URIهایی طراحی کنیم که هم برای انسانها قابل فهم باشن و هم با استانداردهای وب سازگار باشن.
⭕️ از جداکنندهی اسلش (/) برای نشان دادن رابطهی سلسلهمراتبی استفاده کنید.
کاراکتر اسلش (/) در بخش مسیر (path) یک URI برای نشان دادن رابطهی سلسلهمراتبی بین منابع استفاده میشه. به عنوان مثال:
فرض کنید یک سایت دارید که شامل کشورها و شهرهاست. در این حالت، URI شما میتونه به این شکل باشه:
http://api.example.com/countries/iran/tehran
در این مثال، "iran" زیرمجموعهای از "countries" و "tehran" زیرمجموعهای از "iran" هست، که با استفاده از اسلش (/) این ساختار سلسلهمراتبی نشون داده شده.
این کار کمک میکنه تا URIها به شکلی ساختاریافته و قابل درک برای کاربران و توسعهدهندگان باشند.
⭕️ نباید از اسلش (/) درآخر URI ها استفاده کنید
وقتی اسلش (/) به عنوان آخرین کاراکتر در مسیر (path) یک URI قرار میگیره، هیچ ارزش معنایی اضافهای نداره و ممکنه باعث سردرگمی بشه. بنابراین، REST APIها نباید انتظار داشته باشند که URIها با یک اسلش انتهایی تموم بشند و نباید این نوع لینکها رو به کاربران ارائه بدهند.
بسیاری از اجزای وب و فریمورکها، این دو URI رو به طور یکسان در نظر میگیرند:
http://api.canvas.restapi.org/shapes/
http://api.canvas.restapi.org/shapes
اما واقعیت اینه که هر کاراکتر در یک URI به شناسایی منحصر به فرد اون منبع کمک میکنه. دو URI متفاوت به دو منبع متفاوت اشاره میکنند. بنابراین، یک REST API باید URIهای تمیز و دقیق تولید کنه و نباید تلاشهای کاربران برای شناسایی منابع به شکل نادرست رو بپذیره.
البته، APIهای منعطفتر ممکنه کاربران رو به URIهایی بدون اسلش انتهایی هدایت کنند (همونطور که در قانون مربوط به استفاده از کد وضعیت 301 "Moved Permanently" برای جابجایی منابع توضیح داده شده).
⭕️ برای بهبود خوانایی URIها از خط تیره (-) استفاده کنید
برای اینکه URIهاتون رو برای افراد قابل فهم و قابل اسکن کنید، از کاراکتر خط تیره (-) استفاده کنید تا خوانایی نامها در بخشهای طولانی مسیر (path) بهتر بشه. هر جایی که در زبان انگلیسی از فاصله یا خط تیره استفاده میکنید، در URI هم باید از خط تیره استفاده کنید. به عنوان مثال:
http://api.example.restapi.org/blogs/mark-masse/entries/this-is-my-first-post
این کار باعث میشه که URIها هم از نظر ظاهری بهتر و هم از نظر فهم و کاربرد راحتتر بشند.
#کتاب
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل اول: معرفی (Introduction)
📍پارت: چهارم (پارت آخر فصل اول)
#کتاب
💎 WRML 💎
من (نویسنده کتاب) یه چارچوب مفهومی به نام Web Resource Modeling Language (WRML) اختراع کردم که به طراحی و پیادهسازی REST API ها کمک میکنه. WRML، که به صورت "ورمل" تلفظ میشه، اول به عنوان یه تکنیک برای رسم مدل منابع به وجود اومد که از یه سری اشکال ساده برای نمایش هر کدوم از الگوهای منابع استفاده میکنه.
دامنهی WRML با ایجاد نوع رسانهای به نام
در فصلهای ۵ و ۶ متوجه میشی که خیلی از قوانین با مثالهایی که از JSON استفاده میکنن، توضیح داده شدن. JSON یه فرمت مهمه که مزایای زیادی داره، مثل پشتیبانی بومی از جاوااسکریپت، پذیرش تقریبا جهانی، و سینتکس آشنا. اما JSON به تنهایی ساختارهای یکسانی برای بعضی از مهمترین مفاهیم REST API مثل لینکها، روابط لینکها، و اسکیمها ارائه نمیده. قوانین توی فصلهای "نمایش هایپرمیدیا" و "نمایش اسکیم" از WRML استفاده میکنن تا فرمهای نمایشی مبتنی بر JSON رو برای این ساختارهای اصلی نشون بدن.
در نهایت، فصل ۷ تأکید میکنه که یکنواختی در طراحی API فقط یه موضوع تئوری نیست؛ بلکه میتونه زندگی برنامهنویسا رو بهتر کنه و به ما ابزاری غنی بده تا با استفاده از اونها REST API های بهتری طراحی و توسعه بدیم.
✅ خلاصه
این فصل خلاصهای از اختراع و تثبیت وب رو ارائه داد. همچنین به معرفی رویکرد قوانینمحور کتاب و چارچوب مفهومی WRML پرداخت، که ایدههای اون به طراحی یکپارچه REST API کمک میکنن. فصلهای بعدی بر این پایه استوار میشن تا به ما کمک کنن که از REST در طراحی API استفاده کنیم.
جدول ۱-۱ هم خلاصهای از اصطلاحات جدیدی که توی این فصل معرفی شدن رو ارائه میده.
@ninja_learn_ir
📌 فصل اول: معرفی (Introduction)
📍پارت: چهارم (پارت آخر فصل اول)
#کتاب
💎 WRML 💎
من (نویسنده کتاب) یه چارچوب مفهومی به نام Web Resource Modeling Language (WRML) اختراع کردم که به طراحی و پیادهسازی REST API ها کمک میکنه. WRML، که به صورت "ورمل" تلفظ میشه، اول به عنوان یه تکنیک برای رسم مدل منابع به وجود اومد که از یه سری اشکال ساده برای نمایش هر کدوم از الگوهای منابع استفاده میکنه.
دامنهی WRML با ایجاد نوع رسانهای به نام
application/wrml که قابلیت اضافه کردن فرمت و اجزای اسکیمای جدید رو داره، گستردهتر شد. در خیلی از قواعد بعدی کتاب، از ایدههای WRML استفاده میکنم تا شکافهای موجود در بهترین روشهای فعلی رو با توصیههای منطقی برای موقعیتهای رایج پر کنم.در فصلهای ۵ و ۶ متوجه میشی که خیلی از قوانین با مثالهایی که از JSON استفاده میکنن، توضیح داده شدن. JSON یه فرمت مهمه که مزایای زیادی داره، مثل پشتیبانی بومی از جاوااسکریپت، پذیرش تقریبا جهانی، و سینتکس آشنا. اما JSON به تنهایی ساختارهای یکسانی برای بعضی از مهمترین مفاهیم REST API مثل لینکها، روابط لینکها، و اسکیمها ارائه نمیده. قوانین توی فصلهای "نمایش هایپرمیدیا" و "نمایش اسکیم" از WRML استفاده میکنن تا فرمهای نمایشی مبتنی بر JSON رو برای این ساختارهای اصلی نشون بدن.
در نهایت، فصل ۷ تأکید میکنه که یکنواختی در طراحی API فقط یه موضوع تئوری نیست؛ بلکه میتونه زندگی برنامهنویسا رو بهتر کنه و به ما ابزاری غنی بده تا با استفاده از اونها REST API های بهتری طراحی و توسعه بدیم.
✅ خلاصه
این فصل خلاصهای از اختراع و تثبیت وب رو ارائه داد. همچنین به معرفی رویکرد قوانینمحور کتاب و چارچوب مفهومی WRML پرداخت، که ایدههای اون به طراحی یکپارچه REST API کمک میکنن. فصلهای بعدی بر این پایه استوار میشن تا به ما کمک کنن که از REST در طراحی API استفاده کنیم.
جدول ۱-۱ هم خلاصهای از اصطلاحات جدیدی که توی این فصل معرفی شدن رو ارائه میده.
@ninja_learn_ir
#کتاب
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل اول: معرفی (Introduction)
📍پارت: سوم
#کتاب
💎 REST 💎
در سال ۲۰۰۰، بعد از اینکه مشکل مقیاسپذیری وب حل شد، فیلدینگ تو پایاننامه دکترای خودش سبک معماری وب رو اسمگذاری کرد و اسمش رو "انتقال حالت نمایشی" یا همون REST رو برای این سبک معماری انتخاب کرد. این سبک شامل محدودیتهایی هست که قبلاً بهشون اشاره کردیم.
💎 REST API ها 💎
وب سرویسها (Web Services) سرورهای مخصوصی هستن که نیازهای یه سایت یا هر اپلیکیشن دیگهای رو برطرف میکنن.
برنامههای کلاینت (یا همون نرمافزارهایی که با سرور ارتباط میگیرن) از طریق API با این وب سرویسها ارتباط برقرار میکنن.
به زبان ساده، API ها یه سری داده و عملکرد رو در اختیار برنامههای دیگه قرار میدن تا بتونن با هم تعامل کنن و اطلاعات رد و بدل کنن.
یه وب API مثل ویترین یه وب سرویسه که مستقیماً درخواستهای کلاینت رو میشنوه و بهشون جواب میده.
سبک معماری REST معمولاً برای طراحی API های وب سرویسهای مدرن استفاده میشه. اگه یه وب API با سبک معماری REST طراحی شده باشه، بهش میگیم REST API.
⭕️ نکات:
مقیاسپذیری: یعنی یه سیستم بتونه بدون کاهش کیفیت، با افزایش ترافیک (مثلا تعداد کاربران) کنار بیاد و بتونه هندلشون کنه.
کلاینت: دستگاه یا نرمافزاری که به سرور وصل میشه و ازش درخواست میکنه. مثلاً مرورگر وب که به یه سایت وصل میشه.
وب سرویس: یه سرویس تحت وب که از طریق اینترنت قابل دسترسیه و خدمات خاصی رو ارائه میده.
API: یه واسطه که به برنامهها اجازه میده با هم ارتباط برقرار کنن.
وقتی یه وب سرویس از REST API استفاده کنه، بهش میگیم که اون سرویس "RESTful" هست. یه REST API از یه سری منابع به هم پیوسته تشکیل شده که بهشون مدل منابع (Resource Model) گفته میشه. REST API هایی که خوب طراحی شده باشن، میتونن برنامهنویسهای کلاینت رو جذب کنن تا از اون وب سرویس استفاده کنن. امروزه که سرویسهای وب رقیب دارن با هم برای جلب توجه رقابت میکنن، داشتن یه REST API با طراحی تمیز و کاربرپسند یه ویژگی ضروریه.
طراحی REST API برای خیلی از ماها بیشتر شبیه یه هنره تا یه علم. یه سری از بهترین روشها برای طراحی REST API توی استاندارد HTTP وجود داره، ولی یه سری روشهای دیگه هم طی سالهای اخیر بهصورت نیمهاستاندارد شکل گرفته.
با این حال، هنوز هم باید دنبال جواب برای یه سری سوالات مهم بگردیم، مثلا:
- کی باید اسم route هامون رو با اسمهای جمع بنویسیم؟
- از کدوم متد ریکوست (مثل POST یا PUT) باید برای بهروزرسانی وضعیت منابع استفاده کنیم؟
- چطور باید عملیاتهایی که مربوط به CRUD نیستن (CRUD: ایجاد، خواندن، بهروزرسانی، حذف) رو به route ها مپ کنیم؟
- کدوم کد استاتوس HTTP برای یه سناریوی خاص مناسبه؟
- چطور میتونم نسخههای مختلف نمایههای وضعیت یه منبع رو مدیریت کنم؟
- چطور باید لینکها رو توی JSON ساختاردهی کنم؟
⭕️ نکات:
- URI آدرس مشخصی که برای دسترسی به یه منبع توی وب استفاده میشه.
- CRUD مخفف چهار عمل اصلی روی دادهها؛ ایجاد (Create)، خواندن (Read)، بهروزرسانی (Update)، و حذف (Delete).
- HTTP Status Code کدهایی که وضعیت درخواستهای HTTP رو نشون میدن، مثل 200 برای موفقیتآمیز بودن یا 404 برای پیدا نشدن.
این کتاب یه سری قوانین طراحی REST API رو معرفی میکنه که هدفش اینه تا جوابهای واضح و مختصری به سوالات مهمی که مطرح کردیم، بده.
این قوانین میخوان بهت کمک کنن تا REST API هایی با یکپارچگی و نظم طراحی کنی که بتونن بهخوبی توسط کلاینتهایی که ازشون استفاده میکنن، بهرهبرداری بشن. میتونی این قوانین رو کامل دنبال کنی یا هر کدوم که دوست داشتی انتخاب کنی. شاید با بعضی از این قوانین مخالفت کنی، ولی من معتقدم هر کدومشون ارزش بررسی دقیق رو دارن.
خیلی از قوانین طراحی این کتاب از بهترین روشهایی گرفته شدن که بهنوعی استانداردهای نانوشتهای شدهان. اگه تجربهای توی طراحی REST API ها داری، احتمالاً با قوانینی که مربوط به طراحی URI در فصل ۲ و استفاده از HTTP در فصل ۳ هستن، آشنا خواهی بود. ولی در مقابل، بیشتر قوانین فصل ۴ و فصل ۵ (مخصوصاً اونایی که به نوع دادهها و فرمهای نمایشی مربوط میشن) راهحلهایی هستن که خودم برای مسائلی که توافقی روشون نیست، ارائه دادم.
@ninja_learn_ir
📌 فصل اول: معرفی (Introduction)
📍پارت: سوم
#کتاب
💎 REST 💎
در سال ۲۰۰۰، بعد از اینکه مشکل مقیاسپذیری وب حل شد، فیلدینگ تو پایاننامه دکترای خودش سبک معماری وب رو اسمگذاری کرد و اسمش رو "انتقال حالت نمایشی" یا همون REST رو برای این سبک معماری انتخاب کرد. این سبک شامل محدودیتهایی هست که قبلاً بهشون اشاره کردیم.
💎 REST API ها 💎
وب سرویسها (Web Services) سرورهای مخصوصی هستن که نیازهای یه سایت یا هر اپلیکیشن دیگهای رو برطرف میکنن.
برنامههای کلاینت (یا همون نرمافزارهایی که با سرور ارتباط میگیرن) از طریق API با این وب سرویسها ارتباط برقرار میکنن.
به زبان ساده، API ها یه سری داده و عملکرد رو در اختیار برنامههای دیگه قرار میدن تا بتونن با هم تعامل کنن و اطلاعات رد و بدل کنن.
یه وب API مثل ویترین یه وب سرویسه که مستقیماً درخواستهای کلاینت رو میشنوه و بهشون جواب میده.
سبک معماری REST معمولاً برای طراحی API های وب سرویسهای مدرن استفاده میشه. اگه یه وب API با سبک معماری REST طراحی شده باشه، بهش میگیم REST API.
⭕️ نکات:
مقیاسپذیری: یعنی یه سیستم بتونه بدون کاهش کیفیت، با افزایش ترافیک (مثلا تعداد کاربران) کنار بیاد و بتونه هندلشون کنه.
کلاینت: دستگاه یا نرمافزاری که به سرور وصل میشه و ازش درخواست میکنه. مثلاً مرورگر وب که به یه سایت وصل میشه.
وب سرویس: یه سرویس تحت وب که از طریق اینترنت قابل دسترسیه و خدمات خاصی رو ارائه میده.
API: یه واسطه که به برنامهها اجازه میده با هم ارتباط برقرار کنن.
وقتی یه وب سرویس از REST API استفاده کنه، بهش میگیم که اون سرویس "RESTful" هست. یه REST API از یه سری منابع به هم پیوسته تشکیل شده که بهشون مدل منابع (Resource Model) گفته میشه. REST API هایی که خوب طراحی شده باشن، میتونن برنامهنویسهای کلاینت رو جذب کنن تا از اون وب سرویس استفاده کنن. امروزه که سرویسهای وب رقیب دارن با هم برای جلب توجه رقابت میکنن، داشتن یه REST API با طراحی تمیز و کاربرپسند یه ویژگی ضروریه.
طراحی REST API برای خیلی از ماها بیشتر شبیه یه هنره تا یه علم. یه سری از بهترین روشها برای طراحی REST API توی استاندارد HTTP وجود داره، ولی یه سری روشهای دیگه هم طی سالهای اخیر بهصورت نیمهاستاندارد شکل گرفته.
با این حال، هنوز هم باید دنبال جواب برای یه سری سوالات مهم بگردیم، مثلا:
- کی باید اسم route هامون رو با اسمهای جمع بنویسیم؟
- از کدوم متد ریکوست (مثل POST یا PUT) باید برای بهروزرسانی وضعیت منابع استفاده کنیم؟
- چطور باید عملیاتهایی که مربوط به CRUD نیستن (CRUD: ایجاد، خواندن، بهروزرسانی، حذف) رو به route ها مپ کنیم؟
- کدوم کد استاتوس HTTP برای یه سناریوی خاص مناسبه؟
- چطور میتونم نسخههای مختلف نمایههای وضعیت یه منبع رو مدیریت کنم؟
- چطور باید لینکها رو توی JSON ساختاردهی کنم؟
⭕️ نکات:
- URI آدرس مشخصی که برای دسترسی به یه منبع توی وب استفاده میشه.
- CRUD مخفف چهار عمل اصلی روی دادهها؛ ایجاد (Create)، خواندن (Read)، بهروزرسانی (Update)، و حذف (Delete).
- HTTP Status Code کدهایی که وضعیت درخواستهای HTTP رو نشون میدن، مثل 200 برای موفقیتآمیز بودن یا 404 برای پیدا نشدن.
این کتاب یه سری قوانین طراحی REST API رو معرفی میکنه که هدفش اینه تا جوابهای واضح و مختصری به سوالات مهمی که مطرح کردیم، بده.
این قوانین میخوان بهت کمک کنن تا REST API هایی با یکپارچگی و نظم طراحی کنی که بتونن بهخوبی توسط کلاینتهایی که ازشون استفاده میکنن، بهرهبرداری بشن. میتونی این قوانین رو کامل دنبال کنی یا هر کدوم که دوست داشتی انتخاب کنی. شاید با بعضی از این قوانین مخالفت کنی، ولی من معتقدم هر کدومشون ارزش بررسی دقیق رو دارن.
خیلی از قوانین طراحی این کتاب از بهترین روشهایی گرفته شدن که بهنوعی استانداردهای نانوشتهای شدهان. اگه تجربهای توی طراحی REST API ها داری، احتمالاً با قوانینی که مربوط به طراحی URI در فصل ۲ و استفاده از HTTP در فصل ۳ هستن، آشنا خواهی بود. ولی در مقابل، بیشتر قوانین فصل ۴ و فصل ۵ (مخصوصاً اونایی که به نوع دادهها و فرمهای نمایشی مربوط میشن) راهحلهایی هستن که خودم برای مسائلی که توافقی روشون نیست، ارائه دادم.
@ninja_learn_ir
#کتاب
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل اول: معرفی (Introduction)
📍پارت: دوم
#کتاب
💎 معماری وب 💎
در اواخر سال ۱۹۹۳، "روی فیلدینگ"، یکی از بنیانگذاران پروژه سرور HTTP آپاچی، نگران مشکل مقیاسپذیری وب شد.
بعد از تحلیل، فیلدینگ متوجه شد که مقیاسپذیری وب تحت تأثیر یه سری محدودیتهای کلیدی قرار داره. اون و دیگران تصمیم گرفتن که با یه رویکرد عملیاتی، وب رو بهبود بدن: باید همه این محدودیتها رو بهصورت یکسان برآورده کنن تا وب بتونه به گسترش خودش ادامه بده.
فیلدینگ این محدودیتها رو به شش دسته تقسیم کرد و به مجموعه این دستهها "سبک معماری وب" گفت:
۱. کلاینت-سرور (Client-server)
۲. رابط یکپارچه (Uniform interface)
۳. سیستم لایهای (Layered system)
۴. کش (Cache)
۵. بدون حالت (Stateless)
۶. کد بهصورت درخواستی (Code-on-demand)
1️⃣ کلاینت-سرور (Client-server)
موضوع اصلی محدودیتهای کلاینت-سرور در وب، جداسازی وظایف است. وب یک سیستم مبتنی بر کلاینت-سرور است که در آن کلاینتها و سرورها نقشهای مجزا و مشخصی دارند. این بخشها میتوانند بهصورت مستقل پیادهسازی و مستقر شوند، با استفاده از هر زبان یا فناوری، به شرطی که با رابط یکنواخت وب سازگار باشند.
2️⃣ رابط یکپارچه (Uniform interface)
تعاملات بین اجزای وب، یعنی کلاینتها، سرورها و واسطههای مبتنی بر شبکه، به یکنواختی رابطهایشان بستگی دارد. اگر هر یک از این اجزا از استانداردهای تعیینشده خارج شوند، سیستم ارتباطی وب دچار اختلال میشود.
اجزای وب در چارچوب چهار محدودیت رابط یکنواخت که فیلدینگ شناسایی کرده است، بهطور سازگار با هم کار میکنند:
1- شناسایی منابع
2- دستکاری منابع از طریق نمایهها
3- پیامهای خودتوصیفی
4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)
1- شناسایی منابع
هر مفهوم مجزای مبتنی بر وب به عنوان یک منبع شناخته میشود و میتواند با یک شناسه یکتا، مثل URI، مورد خطاب قرار گیرد. برای مثال، یک URI خاص مثل http://www.google.com منحصراً به مفهوم ریشهی یک وبسایت خاص اشاره دارد.
2- دستکاری منابع از طریق نمایهها
کلاینتها نمایههای منابع را دستکاری میکنند. یک منبع مشخص میتواند به شکلهای مختلف برای کلاینتهای مختلف نمایه شود. مثلاً، یک سند ممکن است بهصورت HTML به یک مرورگر وب نمایش داده شود و بهصورت JSON به یک برنامه خودکار. ایده کلیدی این است که نمایهها راهی برای تعامل با منبع هستند، اما خود منبع نیستند. این تمایز مفهومی اجازه میدهد که منبع به روشها و فرمتهای مختلف نمایه شود بدون اینکه شناسهاش تغییر کند.
3- پیامهای خودتوصیفی (Self-denoscriptive)
وضعیت مورد نظر یک منبع میتواند در پیام درخواست کلاینت نمایه شود. وضعیت کنونی منبع ممکن است در پیام پاسخ سرور که بازمیگردد، نمایش داده شود. بهعنوان مثال، یک ویرایشگر صفحه ویکی ممکن است از پیام درخواست برای انتقال یک نمایه که پیشنهاد یک بروزرسانی صفحه (وضعیت جدید) برای یک صفحه وب مدیریتشده توسط سرور است، استفاده کند. سرور تصمیم میگیرد که درخواست کلاینت را بپذیرد یا رد کند.
4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)
نمایش وضعیت یک منبع شامل لینکهایی به منابع مرتبط هست. لینکها مثل نخهایی هستند که وب رو به هم متصل میکنن و به کاربرا این امکان رو میدن که به صورت معنادار و هدفمند بین اطلاعات و برنامهها حرکت کنن. وجود یا نبودن یه لینک روی یک صفحه، بخش مهمی از وضعیت فعلی اون منبعه.
3️⃣ سیستم لایهای (Layered system)
محدودیتهای سیستم لایهای این امکان رو میده که واسطههای مبتنی بر شبکه مثل پروکسیها و درگاهها، بهصورت شفاف بین کلاینت و سرور مستقر بشن و از رابط یکنواخت وب استفاده کنن. بهطور کلی، یه واسطه مبتنی بر شبکه برای یه هدف مشخص ارتباط کلاینت و سرور رو رهگیری میکنه. این واسطهها معمولاً برای اجرای امنیت، کش کردن پاسخها و متعادل کردن بار ترافیکی استفاده میشن.
4️⃣ کش (Cache)
کش کردن یکی از مهمترین محدودیتهای معماری وب هست. محدودیتهای مربوط به کش به سرور وب میگن که باید قابلیت کش شدن دادههای هر پاسخ رو مشخص کنه. کش کردن دادههای پاسخ میتونه به کاهش تأخیر احساسشده توسط کاربر، افزایش دسترسیپذیری و قابلیت اطمینان یک برنامه، و کنترل بار سرور وب کمک کنه. به طور خلاصه، کش کردن هزینه کلی وب رو کاهش میده.
کش میتونه در هر جایی از مسیر شبکه بین کلاینت و سرور وجود داشته باشه. این کشها ممکنه در شبکه سرور وب یک سازمان، داخل شبکههای تحویل محتوای تخصصی (CDNها) یا حتی داخل خود کلاینت باشن.
📌 فصل اول: معرفی (Introduction)
📍پارت: دوم
#کتاب
💎 معماری وب 💎
در اواخر سال ۱۹۹۳، "روی فیلدینگ"، یکی از بنیانگذاران پروژه سرور HTTP آپاچی، نگران مشکل مقیاسپذیری وب شد.
بعد از تحلیل، فیلدینگ متوجه شد که مقیاسپذیری وب تحت تأثیر یه سری محدودیتهای کلیدی قرار داره. اون و دیگران تصمیم گرفتن که با یه رویکرد عملیاتی، وب رو بهبود بدن: باید همه این محدودیتها رو بهصورت یکسان برآورده کنن تا وب بتونه به گسترش خودش ادامه بده.
فیلدینگ این محدودیتها رو به شش دسته تقسیم کرد و به مجموعه این دستهها "سبک معماری وب" گفت:
۱. کلاینت-سرور (Client-server)
۲. رابط یکپارچه (Uniform interface)
۳. سیستم لایهای (Layered system)
۴. کش (Cache)
۵. بدون حالت (Stateless)
۶. کد بهصورت درخواستی (Code-on-demand)
1️⃣ کلاینت-سرور (Client-server)
موضوع اصلی محدودیتهای کلاینت-سرور در وب، جداسازی وظایف است. وب یک سیستم مبتنی بر کلاینت-سرور است که در آن کلاینتها و سرورها نقشهای مجزا و مشخصی دارند. این بخشها میتوانند بهصورت مستقل پیادهسازی و مستقر شوند، با استفاده از هر زبان یا فناوری، به شرطی که با رابط یکنواخت وب سازگار باشند.
2️⃣ رابط یکپارچه (Uniform interface)
تعاملات بین اجزای وب، یعنی کلاینتها، سرورها و واسطههای مبتنی بر شبکه، به یکنواختی رابطهایشان بستگی دارد. اگر هر یک از این اجزا از استانداردهای تعیینشده خارج شوند، سیستم ارتباطی وب دچار اختلال میشود.
اجزای وب در چارچوب چهار محدودیت رابط یکنواخت که فیلدینگ شناسایی کرده است، بهطور سازگار با هم کار میکنند:
1- شناسایی منابع
2- دستکاری منابع از طریق نمایهها
3- پیامهای خودتوصیفی
4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)
1- شناسایی منابع
هر مفهوم مجزای مبتنی بر وب به عنوان یک منبع شناخته میشود و میتواند با یک شناسه یکتا، مثل URI، مورد خطاب قرار گیرد. برای مثال، یک URI خاص مثل http://www.google.com منحصراً به مفهوم ریشهی یک وبسایت خاص اشاره دارد.
2- دستکاری منابع از طریق نمایهها
کلاینتها نمایههای منابع را دستکاری میکنند. یک منبع مشخص میتواند به شکلهای مختلف برای کلاینتهای مختلف نمایه شود. مثلاً، یک سند ممکن است بهصورت HTML به یک مرورگر وب نمایش داده شود و بهصورت JSON به یک برنامه خودکار. ایده کلیدی این است که نمایهها راهی برای تعامل با منبع هستند، اما خود منبع نیستند. این تمایز مفهومی اجازه میدهد که منبع به روشها و فرمتهای مختلف نمایه شود بدون اینکه شناسهاش تغییر کند.
3- پیامهای خودتوصیفی (Self-denoscriptive)
وضعیت مورد نظر یک منبع میتواند در پیام درخواست کلاینت نمایه شود. وضعیت کنونی منبع ممکن است در پیام پاسخ سرور که بازمیگردد، نمایش داده شود. بهعنوان مثال، یک ویرایشگر صفحه ویکی ممکن است از پیام درخواست برای انتقال یک نمایه که پیشنهاد یک بروزرسانی صفحه (وضعیت جدید) برای یک صفحه وب مدیریتشده توسط سرور است، استفاده کند. سرور تصمیم میگیرد که درخواست کلاینت را بپذیرد یا رد کند.
4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)
نمایش وضعیت یک منبع شامل لینکهایی به منابع مرتبط هست. لینکها مثل نخهایی هستند که وب رو به هم متصل میکنن و به کاربرا این امکان رو میدن که به صورت معنادار و هدفمند بین اطلاعات و برنامهها حرکت کنن. وجود یا نبودن یه لینک روی یک صفحه، بخش مهمی از وضعیت فعلی اون منبعه.
3️⃣ سیستم لایهای (Layered system)
محدودیتهای سیستم لایهای این امکان رو میده که واسطههای مبتنی بر شبکه مثل پروکسیها و درگاهها، بهصورت شفاف بین کلاینت و سرور مستقر بشن و از رابط یکنواخت وب استفاده کنن. بهطور کلی، یه واسطه مبتنی بر شبکه برای یه هدف مشخص ارتباط کلاینت و سرور رو رهگیری میکنه. این واسطهها معمولاً برای اجرای امنیت، کش کردن پاسخها و متعادل کردن بار ترافیکی استفاده میشن.
4️⃣ کش (Cache)
کش کردن یکی از مهمترین محدودیتهای معماری وب هست. محدودیتهای مربوط به کش به سرور وب میگن که باید قابلیت کش شدن دادههای هر پاسخ رو مشخص کنه. کش کردن دادههای پاسخ میتونه به کاهش تأخیر احساسشده توسط کاربر، افزایش دسترسیپذیری و قابلیت اطمینان یک برنامه، و کنترل بار سرور وب کمک کنه. به طور خلاصه، کش کردن هزینه کلی وب رو کاهش میده.
کش میتونه در هر جایی از مسیر شبکه بین کلاینت و سرور وجود داشته باشه. این کشها ممکنه در شبکه سرور وب یک سازمان، داخل شبکههای تحویل محتوای تخصصی (CDNها) یا حتی داخل خود کلاینت باشن.
Forwarded from Ninja Learn | نینجا لرن
ضمن خوش آمد گویی به دوستانی که تازه به جمعمون اضافه شدن 🌹، باید بگم که ما هر روز بخشی از خلاصه کتاب REST API Design Rulebook رو داخل کانال منتشر میکنیم و میتونید مطالعه کنید.
فایل PDF هم قبلا آپلود شده، فقط کافیه سرچ بزنید 🔎
از هشتگ #کتاب هم میتونید استفاده کنید برای دسترسی سریعتر #️⃣
استفاده کنید 😄❤️
فایل PDF هم قبلا آپلود شده، فقط کافیه سرچ بزنید 🔎
از هشتگ #کتاب هم میتونید استفاده کنید برای دسترسی سریعتر #️⃣
استفاده کنید 😄❤️