VIP همه چیز درباره برنامه نویسی

[☾♔TALAYEH_A♔☽]

نحوه ی عملکرد اف تی پی


اف تی پی با به کارگیری TCP و IP، آپلود و دانلود داده ها را میان کامپیوترها از طریق شبکه اینترنت میسر می سازد. اصطلاح TCP مخفف واژگان Transmission Control Protocol به معنی «پروتوکل کنترل انتقال داده ها» و IP مخفف واژگان Internet Protocol به معنی «پروتوکل اینترنتی» است. به عبارت دیگر تی سی پی به مدیریت نحوه انتقال داده ها از طریق اینترنت می پردازد و این در حالی است که همان طور که در فصول گذشته ذکر شد آی پی مسئول هدایت کردن کاربران به آدرس های دامین است.

برای آن که بتوانیم داده های خود را مابین سرور و کامپیوتر شخصی انتقال دهیم، لازم است تا هم پورت سمت سرور و هم پورت سمت کاربر باز باشد (برای آشنایی بیشتر با پورت ها در شبکه های کامپیوتری به آموزش های گذشته مراجعه نمایید.)

زمانی که می خواهیم از سرور طریق اف تی پی به سرور هاست متصل شویم، ما به عنوان یک کاربر از طریق تی سی پی به پورت 21 سرور اف تی پی نصب شده روی سرور متصل می شویم تا از این پس برای نقل و انتقال داده ها باز باشد. در عوض سرور اف تی پی ارتباط دیگری را ایجاد می کند که این ارتباط ثانویه از طریق پورت 20 با سیستم عامل کاربر برقرار می گردد. از این پس، از طریق آدرس آی پی خواهیم توانست به دایرکتوری های مرتبط با وب سایت خود روی سرور هاست دسترسی پیدا کنیم.

برای روشن شدن مطالب فوق، اتصال به سرور اف تی پی را با اتصال به جیمیل مقایسه می کنیم. در حقیقت زمانی که می خواهیم به اکانت جیمیل خود وارد شویم، می بایست اطلاعاتی همچون آدرس سرور، نام کاربری و رمز عبور را داشته باشیم. به منظور اتصال به سرور اف تی پی نیز می بایست اطلاعات زیر را داشته باشیم:

site:ftp.example.com
login:user
pass:123456
port:21
همان طور که در خط اول ملاحظه می شود، آدرس سرور اف تی پی آمده است. اگر فرض کنیم که آدرس وب سایت ما example.com باشد، با قرار دادن پیشوند ftp قبل از آدرس سایت به سرور اف تی پی متصل خواهیم شد. در خط دوم و سوم نام کاربری و رمز عبور را مشاهده می کنیم و در نهایت شماره پورتی است که از آن طریق به سرور اف تی پی متصل می شویم که پورت 21 است. همان طور که در آموزش های گذشته توضیح داده شد، پورت را می توان به عنوان دروازه ای در نظر گرفت که از طریق آن دروازه می توان وارد سرور هاست شد. با این تفاسیر، سرورها در سراسر دنیا دارای چندین دروازه یا پورت هستند که هر کدام از آن ها برای کار خاصی در نظر گرفته شده اند. به طور مثال، سرور اف تی پی از طریق پورت های 20 و 21 مابین کاربر و سرور هاست ارتباط برقرار می سازد اما این در حالی است که اچ تی تی پی به صورت پیش فرض از طریق پورت 80 به سرور هاست متصل می شود.

 

[☾♔TALAYEH_A♔☽]

نرم افزارهای مشهور اف تی پی


در این آموزش قصد داریم به معرفی دو مورد از معروف ترین نرم افزارهای اف تی پی و مقایسه ی قابلیت های آن ها بپردازیم. لازم به ذکر است استفاده از این دست نرم افزارها به مراتب فرایند ارتباط با سرور را راحت تر ساخته و توسعه دهندگان در یک محیط گرافیکی خواهند توانست به آپلود و یا دانلود فایل های مد نظر خود بپردازند.

FileZilla
یکی از معروف ترین نرم افزارهای اف تی پی در دنیا نرم افزار FileZilla است که از مهم ترین ویژگی های این نرم افزار می توان به موارد زیر اشاره کرد:

- سهولت استفاده
- رایگان بودن
- متن باز بودن
- پشتیبانی از سیستم عامل های مختلفی همچون ویندوز، لینوکس و مکینتاش
- سرعت بالا
- ایمن
- پشتیبانی از زبان های مختلف
- امکان جستجو
- قابلیت Drag & Drop به منظور دانلود و یا آپلود فایل
- و بسیاری ویژگی منحصر به فرد دیگر.

لازم به ذکر است که این نرم افزار دارای دو نسخه می باشد که نسخه سمت کاربر آن به گونه ای طراحی شده است که کلیه سیستم عامل ها را پشتیبانی می کند اما این در حالی است که نسخه سمت سرور آن فقط سیستم عامل ویندوز را پشتیبانی می کند.

Transmit
نرم افزار اف تی پی دیگری که از معروفیت نسبتاً قابل توجهی مابین توسعه دهندگان وب سایت برخوردار است نرم افزاری است تحت عنوان Transmit. این نرم افزار صرفاً برای سیستم عامل مکینتاش طراحی شده است بنابراین کاربران دیگر سیستم عامل ها نمی توانند از این نرم افزار استفاده کنند. از جمله دیگر محدودیت های این نرم افزار این است که رایگان نمی باشد بنابراین جهت استفاده از این نرم افزار می بایست هزینه ی آن را پرداخت کرد:

اما به هر حال قابلیت هایی دارا است که برشمردن آن ها خالی از لطف نیست که عبارتند از:

- استفاده از فناوری Twin-Turbo Engine برای افزایش سرعت انتقال تا 25 برابر
- عدم توقف در انتقال داده در صورت مواجهه با ارور
- پشتیبانی از رایانش ابری
- آپدیت خودکار نرم افزار و ...

 

[☾♔TALAYEH_A♔☽]

نکات امنیتی اف تی پی و آشنایی با روش های اتصال امن SFTP و FTPS


اف تی پی از نقطه نظر امنیتی دارای نقاظ ضعف بسیاری است. در حقیقت از آنجا که کلیه داده ها از طریق سرور اف تی پی در قالب Plain Text یا به عبارتی «متن ساده و بدون هیچ گونه رمز نگاری» روی هاست انتقال داده می شوند، بنابراین کلیه داده ها و همچنین نام کاربری و رمز عبور اف تی پی به سادگی قابل هک شدن توسط افراد سود جو خواهد بود.

هشدار
لازم به ذکر است متاسفانه همواره شاهد مواردی از این سودجویی ها در ایران هستیم به این معنی که ترافیک شما ممکن است توسط یکی از این افراد تحت نظر گرفته شده و رمز عبور اف تی پی سایت به سرقت رود.)
برای رفع این نقطه ضعف، پروتوکل هایی ایمن تر ایجاد شده اند که استفاده از آن ها به منظور نقل و انتقال داده مابین کامپیوتر و سرور اف تی پی از طریق اینترنت به مراتب دارای ضریب ایمنی بیشتری نسبت به اف تی پی می باشند که از جمله ی این پروتوکل ها می توان به روش های اتصال امن SFTP و FTPS اشاره نمود (البته لازم به ذکر است که این پروتوکل ها دارای برتری نسبتاً چشمگیری نسبت به اف تی پی هستند اما این در حالی است که از سرعت به مراتب پایین تری نسبت به اف تی پی برخوردارند و این سرعت پایین متاسفانه در ایران به خاطر سرعت پایین اینترنت مشهود تر می باشد.)

به طور کلی اف تی پی اس نسخه ای از اف تی پی است که این امکان را به کاربران می دهد تا هر عملیات نقل و انتقال داده را رمزنگاری کنند که اینکار با به کارگیری از پروتوکل های Transport Layer Security یا TLS و همچنین Secure Sockets Layer یا SSL امکان پذیر خواهد بود. به عبارت دیگر در این روش، ارتباطاتی که بدون استفاده از پروتوکل های TLS و SSL برقرار می شوند را می توان مسدود کرد.

روش اتصال امن دیگری که می توان مورد استفاده قرار داد اس اف تی پی نام دارد. در این روش از پروتوکلی تحت عنوان Secure Shell برای انتقال داده ها استفاده می شود. در این پروتوکل بر خلاف اف تی پی، هم داده ها و هم دستورات رمزنگاری می شوند که این کار موجب می گردد رمزعبور و دیگر داده های مهم به صورتی روی شبکه قرار نگیرند که قابل مشاهده توسط دیگر کاربران و به عبارتی هکرها باشند.

 

[☾♔TALAYEH_A♔☽]

تفاوت روش های انتقال فایل های ASCII و Binary


در حین انتقال داده ها از طریق شبکه، یکی از دو روش ASCII و یا Binary مورد استفاده قرار می گیرد. اصطلاح ASCII مخفف واژگان American Standard Code for Information Interchange به معنی «کد استاندارد امریکا به منظور تبادل داده ها» می باشد. به طور کلی ASCII در برگیرنده 128 علامت است که کلیه کامپیوترهای دنیا آن ها را می توانند نمایش دهند. این روش برای انتقال متون ساده کاربرد دارد و به هیچ وجه برای انتقال داده هایی به جزء متون توصیه نمی شود و این در حالی است که فایل های زیر را می توان از این روش انتقال داد:

- فایل های متنی
- و فایل های ساده ای همچون اچ تی ام ال
- کدهای CGI

به خاطر داشته باشید
اصطلاح CGI مخفف واژگان Common Gateway Interface است. به طور کلی فایل هایی که با زبان های Scripting مثل پی اچ پی، جاوااسکریپت، پایتون و ... نوشته می شوند تحت عنوان فایل های CGI شناخته می شوند.
روش دیگری که برای انتقال داده ها از طریق اف تی پی توصیه می شود روش Binary است. در حقیقت در این روش سیستم عامل ارسال کننده داده ها اقدام به ارسال داده ها به صورت بایت به بایت می کند و سیستم عامل دریافت کننده اطلاعات کلیه بایت ها را به محض دریافت آن ها یکی پس از دیگری ذخیره می سازد. از جمله فایل های Binary می توان به تصاویر، فایل های زیپ و حتی اپلیکیشن ها اشاره کرد.

چنانچه یک فایل باینتری مثل یک عکس را از روش ASCII منتقل کنیم به طور حتم آن فایل دچار مشکل خواهد شد چرا که روش ASCII برای متون ساده در نظر گرفته شده است اما این در حالی است که روش Binary را می توان هم برای فایل های متنی ساده و هم برای تصاویر و دیگر فایل ها مورد استفاده قرار داد و در اکثر مواقع از این روش به صورت پیش فرض استفاده می شود. به طور کلی فایل های زیر را می توان از این روش انتقال داد:

- فایل های عکس
- اپلیکیشن ها
- فایل های زیپ
- فایل هایی با فرمت های doc, xls, fla, swf
- و به طور کلی هر فایلی که به غیر متون ساده حاوی اطلاعات دیگری باشد.

 

[☾♔TALAYEH_A♔☽]

لاگ ها در اف تی پی

منظور از Log (لاگ) یک فایل متنی است که کلیه کارهایی که در یک عملیات سیستمی رخ می دهد، در آن ثبت می گردد. به طور مثال، در نرم افزار اف تی پی کلیه ی فرایندها اعم از دانلود، آپلود و یا حذف فایلی که صورت می گیرد در این فایل ثبت خواهد شد. بنابراین ادمین سایت قادر خواهد بود روند کاری کاربرانی که از طریق سرور اف تی پی کاری انجام می دهند را پیگیری کند. در قسمت زیر یک نمونه از لاگ اف تی پی آمده است:

Status: Resolving address of example.com
Status: Connecting to 176.9.121.246:21...
Status: Connection established, waiting for welcome message...
Response: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Response: 220-You are user number 5 of 50 allowed.
Response: 220-Local time is now 14:27. Server port: 21.
Response: 220-This is a private system - No anonymous login
Response: 220-IPv6 connections are also welcome on this server.
Response: 220 You will be disconnected after 15 minutes of inactivity.
Command: USER user@example
Response: 331 User user@example OK. Password required
Command: PASS ******
Response: 230-OK. Current restricted directory is /
Response: 230 0 Kbytes used (0%) - authorized: 1024000 Kb
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Extensions supported:
Response: EPRT
Response: IDLE
Response: MDTM
Response: SIZE
Response: MFMT
Response: REST STREAM
Response: MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
Response: MLSD
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: ESTA
Response: PASV
Response: EPSV
Response: SPSV
Response: ESTP
Response: 211 End.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: TYPE I
Response: 200 TYPE is now 8-bit binary
Command: PASV
Response: 227 Entering Passive Mode (176,9,121,246,129,191)
Command: MLSD
Response: 150 Accepted data connection
Response: 226-Options: -a -l
Response: 226 14 matches total
Status: Directory listing successful
اگر فرض کنیم که نام دامین ما example.com است و نام کاربری اکانت افت تی پی user@example است، می توان لاگ فوق را به عنوان یک لاگ واقعی در نظر گرفت. همان طور که در خط دهم می بینیم، ما به عنوان کاربر یک Command (کامند به معنی دستور) برای سرور اف تی پی ارسال می کنیم و در آن دستور به سرور اف تی پی می گوییم که من کاربری هستم به نام user@exampleو سرور اف تی پی هم بلافاصله در خط یازدهم برای ما یک پاسخ ارسال می کند که برای دسترسی به سرور اف تی پی نیاز به رمزعبور دارید. بنابراین در خط دوازدهم رمز عبور خود را برای سرور اف تی پی ارسال می کنیم و پس از آن پاسخ OK با کد اختصاصی 230 به معنی این که با موفقیت توانسته ایم به سرور اف تی پی متصل شویم دریافت می کنیم (لازم به ذکر است که کلیه این کارها به صورت خودکار انجام می شوند.)

 

[☾♔TALAYEH_A♔☽]

ارتباط با سرور اف تی پی از طریق مرورگر


چنانچه به یک نرم افزار اف تی پی همچون فایلزیلا دسترسی نداشته باشیم، به سادگی و با استفاده از یک مرورگر مثل فایرفاکس یا گوگل کروم قادر خواهیم بود تا به سرور اف تی پی متصل شویم اما حتما می بایست دارای یک اکانت اف تی پی و رمز عبور باشیم که این دو را می توان از طریق سی پنل ایجاد کرد. آدرسی که می بایست در مرورگر خود برای ورود به آدرس اف تی پی وارد کنیم به صورت زیر است:

ftp://username[email protected]
همان طور که در آدرس فوق می بینیم، به جای پروتکل http که برای اتصال به نرم افزار وب سرور مورد استفاده قرار می گیرد، از پروتکل ftp استفاده شده است که برای اتصال به سرور اف تی پی است. سپس نام کاربری را نوشته و یک علامت : قرار داده و بلافاصله رمز عبور را وارد می کنیم. سپس یک علامت @ قرار داده عبارت ftp را نوشته و یک نقطه بعد از آن قرار می دهیم و در نهایت آدرس دامین سایت مد نظر را بدون www وارد می کنیم. در واقع آدرس تکمیل شده به صورت زیر خواهد بود:

ftp://[email protected]:[email protected]
حال با فشردن دکمه اینتر می توانیم به سرور اف تی پی متصل شویم. می بینیم که پس از وارد کردن آدرس و فشردن دکمه اینتر وارد سرور اف تی پی می شویم. حال از طریق مرورگر به سادگی قادر خواهیم گشت به فایل های قرار گرفته روی سرور دست یافته و در صورت نیاز آنها را دانلود کرد. نکته ای که در ارتباط با اتصال به سرور اف تی پی از طریق مرورگر وجود دارد این است که کارهایی که از طریق مرورگر می توانیم انجام دهیم به مراتب محدود تر از امکاناتی است که یک نرم افزار اف تی پی در اختیار ما می گذارد. از سوی دیگر امنیت اتصال به سرور افت تی پی از طریق مرورگر به مراتب پایین تر از اتصال به سرور اف تی پی از طریق نرم افزاری همچون فایلزیلا است.

نکته
cPanel که به صورت «سی پنل» خوانده می شود عبارت است از یک کنترل پنلی مدیریت هاست که روی سرورهای لینوکسی نصب می گردد و این امکان را به کاربران چنین سرورهایی می دهد تا در یک محیط گرافیکی -GUI- اقدام به مدیریت اکانت خود، مدیریت فایل ها، ایمیل ها و ... بپردازند. لازم به ذکر است که علاوه بر محیط گرافیکی، سی پنل دارای قابلیت Command Line نیز می باشد که از آن طریق ادمین ها می توانند به برخی از دیگر بخش های سرور خود دسترسی پیدا کنند.

 

[☾♔TALAYEH_A♔☽]

API چیست؟


در حوزهٔ توسعهٔ نرم‌افزار به کرات واژهٔ API به گوش می‌خورد اما اکثر برنامه‌نویسان مبتدی خیلی با ماهیت این اصطلاح آشنا نیستند که در همین راستا در این پُست قصد داریم به طور مفصل با ماهیت و نحوهٔ عملکرد API آشنا شویم اما پیش از هر چیز نیاز به یک مقدمه داریم.

پیش از فراگیر شدن سیستم‌های کامپیوتری در صنایع مختلف، انسان به عنوان کسی که قرار بود با نرم‌افزارهای کامپیوتری بیشترین تعامل را داشته باشد در نظر گرفته می‌شد به طوری که فارغ از کاری که نرم‌افزار انجام می‌داد، از ویرایش تصاویر گرفته تا ارسال ایمیل و غیره، انسان به عنوان موجودیتی که قرار بود با نرم‌افزار مذکور کار کند مرکز توجه قرار داشت به طوری که وی از طریق User Interface یا به اختصار UI به تعامل با نرم‌افزار می‌پرداخت (همان‌گونه که مثلاً امروزه از طریق رابط کاربری محیط دسکتاپ سیستم‌عامل، کارهای مختلفی را انجام می‌دهیم.)

به مرور زمان و پیشرفت فناوری، این نیاز احساس گردید تا به جای تعامل انسان با نرم‌افزار، خودِ نرم‌افزارها نیز بتوانند بدون دخالت انسان با یکدیگر تعامل داشته باشند و این در حالی بود که یک سیستم کامپیوتری بر خلاف انسان چشم و گوش نداشت تا با دیدن رابط کاربری بتواند مثلاً روی دکمهٔ خاصی کلیک کند تا دیتای مد نظرش را به دست آورد مضاف بر اینکه یک نرم‌افزار همچون انسان‌ها نیازی نداشت تا برای ارتباط با نرم‌افزاری دیگر از یک رابط کاربری (UI) زیبا و کاربرپسند برخوردار باشد و اینجا بود که مفهوم API شکل گرفت.

Application Programming Interface چیست؟
API مخفف واژگان Application Programming Interface است که به صورت تحت‌الفظی می‌توان آن را به «رابط برنامه‌نویسی نرم‌افزار» ترجمه کرد. به طور خلاصه، API همچون همان UI است با این تفاوت که به جای انسان، یک سیستم کامپیوتری قرار است با آن تعامل داشته باشد. در واقع، از آنجا که می‌توان واژهٔ Interface را به «فصل مشترک» در فارسی ترجمه کرد، می‌توان گفت که API فصل مشترکی مابین دو نرم‌افزار یا اپلیکیشن است (نیاز به توضیح است که در این بحث واژگانی همچون نرم‌افزار، اپلیکیشن، سیستم و ... می‌توانند به جای یکدیگر استفاده شوند و تفاوت معنایی خاصی ندارند.)

مثالی از دنیای واقعی به منظور درک بهتر مفهوم API
برای درک بهتر این موضوع، چیزی همچون الکتریسته را مد نظر قرار می‌دهیم بدین شکل که می‌توان الکتریسته را به عنوان یک سرویس در نظر گرفت که از طریق پریز برق در اختیار ما قرار می‌گیرد تا انرژی لپ‌تاپ، پنکه، جاروبرقی و هر چیزی که برای کار کردن نیاز به برق داشته باشد را تأمین کند.

اگر بخواهیم در این رابـ ـطه تشبیهی انجام دهیم، سرویسی همچون الکتریسته همچون همان سرویسی است که یک شرکت نرم‌افزاری همچون گوگل در اختیار ما قرار می‌دهد؛ مثلاً به ما اجازه می‌دهد تا به دیتای گوگل‌مپ دسترسی داشته باشیم. حال اپلیکیشن موبایلی که طراحی کرده‌ایم هم نقشی همچون لپ‌تاپ، پنکه یا جاروبرقی را دارد که در مثال قبل برای کار کردن نیاز به الکتریسته داشت اما در این حوزه این اپلیکیشن برای کار کردن نیاز به دیتای گوگل‌مپ دارد.

در حقیقت، در نظر گرفتن یکسری استاندارد در پریزهای برق باعث می‌گردد مصرف‌کننده (که در اینجا انسان نیست بلکه دیوایس‌هایی همچون لپ‌تاپ، پنکه و جاروبرقی است) بدون هیچ‌گونه دغدغه‌ای برق مصرفی خود را تأمین کند. به طور کلی، از جمله مزایای این استاندارد می‌توان به موارد زیر اشاره کرد:

- سازندهٔ وسائل خانگی فقط روی طراحی خود محصولات تمرکز می‌کنند و هیچ کاری به مسائل مربوط به تأمین برق ندارند.
- وسیلهٔ برقی به راحتی می‌تواند به پریزهای برق مختلف وصل شود.
- اگر یک وسیلهٔ برقی را از ایران به انگلستان ببریم،‌ به سادگی با استفاده از یک تبدیل می‌توان از منبع برق ۱۱۰ ولت آن کشور استفاده کرد و کماکان نیازی به ایجاد تغییر روی وسیلهٔ برقی نیست.
- وسیلهٔ برقی اصلاً نمی‌داند که نیروی برق دارد توسط نفت تولید می‌شود یا انرژی خورشیدی بلکه فقط مصرف‌کننده است.
- وسیلهٔ برقی اصلاً نیازی ندارد بداند که انرژی الکتریسته به چه شکلی به دستش رسیده است.
- همچنین پریز برق هم برایش هیچ فرقی نمی‌کند که یک لپ‌تاپ متصل شده است یا پنکه بلکه فقط این وظیفه را دارا است تا به تأمین الکتریسته بپردازد.

حال همان‌طور که برای روشن کردن لپ‌تاپ نیاز داریم تا دوشاخهٔ آداپتور آن را به پریز بزنیم و نیاز به توضیح نیست که ابعاد پریز و دوشاخه از یک استاندارد خاص تبعیت می‌کنند تا بتوانند با یکدیگر جفت شوند (مثلاً پریز برق دارای دو ورودی است و دوشاخ هم دو میله دارد همچنین پریز برق ۲۲۰ ولت عرضه می‌کند و دیوایس هم انتظار دارد برق ۲۲۰ ولت واردش شود نه ۱۱۰ ولت)، ما نیز برای اینکه اپلیکیشن موبایل‌مان بتواند با سرویس گوگل ارتباط برقرار سازد تا مثلاً بتوانیم داخل اپ خود از گوگل‌مپ استفاده نماییم، نیاز به چنین درگاهی داریم که API نام دارد که همچون مثال پریز و دوشاخه، اپلیکیشن موبایل ما و سرویس گوگل‌مپ هم باید از یکسری استاندارد برای ارتباط برقرار کردن با یکدیگر تبعیت کنند که در غیر این صورت چنین ارتباطی هرگز شکل نخواهد گرفت.

همان‌طور که برق وسائل الکتریکی منزل‌مان توسط شبکهٔ توزیع برق تأمین می‌گردد، اپلیکیشن‌های مختلف هم برای دستیابی به دیتای مورد نیاز خود به شبکهٔ اینترنت نیاز دارند.

منظور از Layer of Abstraction چیست؟
‌برای روشن شدن این اصلاح، ابتدا مثالی از API سیستم‌عامل ویندوز می‌زنیم. فرض کنیم دولوپری هستیم که قصد داریم یک نرم‌افزار دسکتاپ برای سیستم‌عامل ویندوز بنویسیم که نیاز به توضیح نیست یکی از بخش‌های نرم‌افزار را هم رابط کاربری (UI) آن است که از طریق پنجره‌های مختلف در معرض دید کاربر قرار می‌گیرد.

فرض کنیم که کمپانی مایکروسافت اقدام به عرضهٔ API اختصاصی ویندوز برای دولوپرهای علاقمند به توسعهٔ نرم‌افزار برای این سیستم‌عامل نمی‌کرد که در چنین فضایی هر دولوپری مجبور می‌شد تا بسته به نیاز و سلیقهٔ خود اقدام به طراحی پنجره‌ها کند و همین مسأله منجر به این می‌شد تا یکپارچگی ظاهری بین نرم‌افزارهای مختلف از بین رود اما این در حالی است که ویندوز از چیزی تحت عنوان Windowing API برخوردار است که یک SDK است که این وظیفه را دارا است تا کلیهٔ مسائل مربوط به ظاهر یک پنجره همچون دکمهٔ بستن، ری‌سایز کردن پنجره و ... را هندل کند و دولوپرها صرفاً نیاز دارند تا چیزهایی همچون اندازهٔ اولیه،‌ عنوان و محتویات داخل پنجره را مشخص کنند و الباقی تنظیمات را به API بسپارند (در ادامه با مفهوم SDK آشنا خواهید شد.)

چنین اتفاقی اصطلاحاً Layer of Abstraction نامیده می‌شود بدین صورت که Windowing API سیستم‌عامل ویندوز به منزلهٔ‌ لایه‌ای انتزاعی است که مابین دولوپر و سیستم‌عامل قرار می‌گیرد تا دولوپر درگیر مسائل فنی،‌ هزاران خط کدی که برای ساخت یک پنجرهٔ‌ ساده نیاز است و ... نگردد و صرفاً با چند خط کد ساده نیاز خود را عملی سازد (در مثال تأمین نیروی الکتریسته هم دقیقاً این لایه‌ٔ انتزاعی وجود دارد بدین شکل که ما به عنوان یک انسان فقط با پریز برق سروکار داریم و اینکه داخل پریز چه اتفاقی می‌افتد، سیم‌های فاز و نول چه رنگی هستند، انرژی چگونه از پُست برق تا سر کنتور می‌آید و ... هیچ ربطی به ما ندارد.)

حال که با مفهوم Layer of Abstraction آشنا شدیم، دیگر نیاز به توضیح نیست که اگر وزارت نیرو اقدام به تغییر زیرساخت‌ها کند، به جای برقی که از سَد می‌آید، برق نیروگاه‌های سیکل ترکیبی را وارد شبکهٔ انتقال برق سازد و یا تجهیزات قرار گرفته داخل پُست‌های انتقال برق را نوسازی کند و کارهایی از این دست، مادامی که انرژی مورد نیاز منازل تأمین گردد، کلیهٔ‌ این تغییرات هیچ فرقی برای مصرف‌کننده نخواهند داشت.

در حوزه توسعهٔ نرم‌افزار، فرض کنیم سرویسی که ما به عنوان یک دولوپر از API مرتبط با آن استفاده می‌کردیم با زبان Java رو روی سرورهای AWS آمازون بود اما شرکت مذکور تصمیم‌ می‌گیرد که آن را با Node.js بازنویسی کرده و روی سرورهای Azure مایکروسافت عرضه کند که در چنین شرایطی مادامی که اصطلاحاً Endpoint مرتبط با آن API تغییر نکند،‌ هیچ فرقی برای دولوپرها نخواهد کرد.

به همین منوال، سرویس‌های عرضه‌‌کنندهٔ API همچون گوگل یا فیسبوک هم مادامی که دست به تغییر استانداردهای خود نزنند و اختلالی در کار دولوپرهایی که پیش از این سرویس‌های آن‌ها را مورد استفاده قرار می‌دادند ایجاد نکنند، به سادگی می‌توانند سرورهای خود را آپگرید کنند،‌ محل فیزیکی دیتاسنترهای خود را تغییر دهند،‌ بین سرویس‌های کلود مختلف سوئیچ کنند و غیره.

به طور مثال، فرض کنیم اپلیکیشنی تحت عنوان «الف» وجود دارد که توسعه‌دهنده‌اش این امکان را برای سایر توسعه‌دهندگان فراهم آورده تا از API آن استفاده کنند. حال فرض کنیم اپلیکیشنی نوشته‌ایم تحت عنوان «ب» و این در حالی است که اپلیکیشن «الف» در چارچوب خاصی به اپلیکیشن «ب» اجازه می‌دهد تا از امکاناتی که دارا است استفاده کند (با مراجعه به سایت ProgrammableWeb می‌توانید به لیست جامعی از API سرویس‌های مختلفی که توسط شرکت‌های مطرحی همچون گوگل،‌ فیسبوک، توییتر و ... عرضه شده‌اند دست یابید.) در عین حال، در حین استفاده از API لازم است یکسری استاندارد حتماً مد نظر قرار داده شوند که برخی از مهم‌ترین آن‌ها عبارتند از:

- دیتایی که از طریق API مبادله می‌گردد ساختاریافته است: به عبارتی، درخواست از طرف نرم‌افزار «ب» در چارچوب یک فرمت استاندارد صورت می‌گیرد که از قبل توسط توسعه‌دهندگان نرم‌افزار «الف» تعریف شده است.
- نتیجهٔ تعامل با API قابل‌پیش‌بینی است: در واقع، درخواست‌هایی که برای نرم‌افزار «الف» ارسال می‌شوند باید در یک چارچوب خاصی باشند و از همین روی پاسخ به چنین درخواست‌هایی همواره مشخص و قابل‌پیش‌بینی خواهند بود.

آشنایی با انواع API
با در نظر گرفتن این نکته که API سازوکاری است که از آن طریق تعامل سیستم با سیستم به جای تعامل کاربر با سیستم صورت می‌گیرد، می‌توان دسته‌بند‌ی‌های مختلفی برای ای‌پی‌آی‌ها در نظر گرفت که عبارتند از:

- ای‌پی‌آی سخت‌افزاری: زمانی که مثلاً با اجرای یک گیم حرفه‌ای فشار زیادی روی سیستم خود می‌آوریم، می‌بینیم که فن سیستم شروع به تند چرخیدن می‌کند و این به دلیل آن است که سی‌پی‌یو نسبت به حالت عادی در معرض فشار بیشتر است و بالتبع داغ شده است و باید خنک گردد که این سازوکار از طریق ارتباط مابین ای‌پی‌آی‌های سخت‌افزاری صورت می‌گیرد.

- ای‌پی‌آی سیستم‌عاملی: پیش از این در قالب مثال توسعهٔ‌ یک نرم‌افزار دسکتاپ توضیح دادیم که ای‌پی‌آی مرتبط با یک سیستم‌عامل همچون ویندوز به چه شکل کار می‌کند.

- ای‌پی‌آی زبان‌های برنامه‌نویسی: زبانی همچون جاوا یک هستهٔ اصلی دارد که شامل سینتکس این زبان، نحوهٔ ساخت متغیر، دیتا تایپ‌ها و ... می‌شود اما در کنار آن‌ها صدها کلاس مختلف توسط توسعه‌دهندگان این زبان عرضه شده که تحت عنوان Java API شناخته می‌شوند که فیچرهای تکمیلی این زبان را در دسترس دولوپرها قرار می‌دهند.

- کیت‌های توسعهٔ نرم‌افزار: Software Development Kit یا به اختصار SDK نیز نوعی دیگی از ای‌پی‌آی‌ها است که توسط شرکت‌های مختلفی همچون گوگل،‌ فیسبوک و ... عرضه می‌شوند تا دولوپرها با استفاده از این کیت‌ها بتوانند اقدام به توسعهٔ نرم‌افزار کنند که از آن جمله می‌توان به Android SDK اشاره کرد.

- ای‌پی‌آی تحت وب (وب سرویس): این نوع ای‌پی‌آی یکی از متداول‌ترین و کاربردی‌ترین انواع ای‌پی‌آی است که ادامه تمرکز روی همین مقوله خواهیم کرد. ای‌پی‌آی تحت وب یا اصطلاحاً Web API به هر پروتکلی گفته می‌شود که از طریق شبکهٔ اینترنت و وب تعامل مابین اپلیکیشن‌های مختلف را امکان‌پذیر سازد و از همین روی Web Service نیز نامیده می‌شود (وب اپلیکیشنی که محتوای خود را از طریق چندین و چند ای‌پی‌آی مختلف تأمین کند اصطلاحاً Mashup نامیده می‌شود.) زمانی که پای ای‌پی‌آی‌های تحت وب به میان می‌آید، باید با سازوکار پروتکل HTTP و HTTPS آشنا باشیم که برای این منظور توصیه می‌کنیم به دورهٔ رایگان وب چگونه کار می‌کند؟ مراجعه نمایید.

درآمدی بر انواع وب سرویس‌ها
به طوری کلی،‌ وب سرویس‌ها را می‌توان به دسته‌های GraphQL ،SOAP ،‌PRC و یکی از معروف‌ترین آن‌ها در حال حاضر REST دسته‌بندی کرد که در ادامه آن‌ها را مورد بررسی قرار خواهیم داد.

- PRC: این اصطلاح مخفف واژگان Programmable Remote Client است. این نوع وب سرویس در دو نوع مدل XML-RPC و JSON-RPC عرضه شده است و همان‌طور که از نام آن‌ها مشخص است، مدل اول از فرمت اکس‌ام‌ال پشتیبانی می‌کند و مدل دوم از جیسون (نیاز به توضیح است که این وب سرویس امروزه کاربرد چندانی ندارد.)

- SOAP: این اصطلاح مخفف واژگان Simple Object Access Protocol است که به منزلهٔ پروتکلی است که متد ارتباطی، نحوهٔ ارسال درخواست، دریافت پاسخ و همچنین فرمت پاسخ‌ها را تعیین می‌کند. به عبارتی، این نوع ای‌پی‌آی راهی است که از آن طریق سیستم‌ها از طریق فرمتی که قابل‌درک برای هر دو طرف کانکشن است می‌توانند با یکدیگر ارتباط برقرار سازند (معمولاً درگاه‌های بانکی از این فرمت پشتبانی می‌کنند.)

- REST: این اصطلاح که مخفف واژگان Representational State Transfer است بر خلاف موارد قبل یک پروتکل حساب نمی‌شود بلکه نوعی معماری است که نسبت به بقیه کاربرد آسان‌تری دارد و به همین دلیل هم هست که امروزه فراگیر شده است که برای کسب اطلاعات بیشتر،‌ می‌توانید به آموزش آشنایی با مفهوم RESTful API و مقالهٔ‌ آشنایی با نحوهٔ استفاده از RESTful API در پایتون مراجعه نمایید.

- GraphQL: استانداردی برای طراحی و توسعهٔ API است که به صورت اپن‌سورس توسط کمپانی فیسبوک توسعه داده شده است که در حقیقت در پاسخ به نقدهایی که به REST وارد است طراحی شده تا بتواند به عنوان راه‌کاری جامع و اثربخش در توسعهٔ ای‌پی‌آی مورد استفاده قرار گیرد.

به خاطر داشته باشیم که دیتا از طریق وب سرویس‌های مختلف به اشکال گوناگونی می‌تواند رد و بدل شود که از جملهٔ مهم‌ترین آن‌ها می‌توان به XML ،JSON و یا HTML اشاره کرد.

تقسیم‌بندی ای‌پی‌آی‌ها از بُعد سطح دسترسی
علاوه بر تقسیم‌بندی‌های فوق،‌ Web API را می‌توان از نقطه نظر سطح دسترسی (پرمیشن) به دسته‌های مختلفی تقسیم‌بندی کرد که عبارتند از:

- Open APIs: این دست ای‌پی‌آی‌ها که اصطلاحاً Public APIs نیز نامیده می‌شوند، بدون هیچ‌گونه محدودیت در سطح دسترسی برای کاربرد B2C در اختیار دولوپرها قرار می‌گیرند که برای مشاهدهٔ لیستی از آن‌ها، می‌توانید به لینک Public APIs در گیت‌هاب مراجعه نمایید.

- Partner APIs: این گروه از ای‌پی‌آی‌ها صرفاً در اختیار کسب‌وکارهای به اصطلاح B2B و B2C است و همچون مورد قبل (Open APIs) هر دولوپری به آن‌ها دسترسی ندارد و معمولاً‌ پولی هستند.

- Internal APIs: این گروه از ای‌پی‌آی‌ها که تحت عنوان Private APIs نیز شناخته می‌شوند، صرفاً برای مصرف داخلی یک سیستم طراحی می‌شوند. به طور مثال،‌ لیست مقالاتی که در سایدبار سمت چپ سکان آکادمی در معرض دید کاربران قرار می‌گیرد از طریق یک Private API (ای‌پی‌آی خصوصی) ایجاد شده که صرفاً برای استفاده توسط خودِ‌ سایت سکان آکادمی توسعه داده شده است.

API Economy چیست؟
کسب درآمد از طریق عرضهٔ ای‌پی‌آی چیزی است که تحت عنوان API Economy شناخته می‌شود. پیش از این گفتیم که برخی ای‌پی‌آی‌ها هستند که اصطلاحاً پابلیک (عمومی)‌ می‌باشند و بالتبع شرکت عرضه‌کننده به صورت مستقیم نمی‌تواند از آن‌ها کسب‌ درآمد کند اما در مقابل برخی شرکت‌ها هم هستند که از طریق عرضهٔ ای‌پی‌آی سرویس‌های اختصاصی خود، به کسب درآمد می‌پردازند بدین شکل که مثلاً تا ده هزار ریکوئست در ماه رایگان است اما اگر به طور مثال اپلیکیشنی طراحی نموده‌ایم که تعداد کاربران زیادی دارد و بالتبع بار بیشتری روی سرورهای شرکت مذکور وارد می‌آورد، برای این منظور باید سرویس پریمیوم خریداری کنیم.

طراحی API
این نکته را همواره باید مد نظر قرار داد که طراحی API از پایه کار نسبتاً دشواری است که مراحلی پیچیده و بسیار تخصصی دارا است. برای آنکه یک تصویر کلی از پروسهٔ طراحی ای‌پی‌آی داشته باشیم، باید گفت که عموماً ای‌پی‌آی‌ها با توجه به برخی الگوها و استانداردها ساخته می‌شوند تا تمامی توسعه‌دهندگان از سراسر دنیا بتوانند بدون سردرگمی از آن‌ها استفاده کنند که بررسی این موضوع خارج از این بحث است.

تأمین امنیت API
اگر همه چیز به درستی و با دقت پیش برود، عرضهٔ API خطری امنیتی برای شما محسوب نمی‌شود اما نیاز به توضیح نیست که هرچه راه‌های ارتباطی با سرورهای خود را بیشتر کنید، راه‌های نفوذ به آن نیز افزایش می‌یابد و از آنجایی که برخی ای‌پی‌آی‌ها به برخی از امکانات سرویس دسترسی می‌دهند که مثلاً تعامل با دیتای ذخیره‌شده روی دیتابیس هم بخشی از آن‌ها است و مسلماً از حساسیت بالایی برخوردار است، می‌تواند در صورت پیاده‌سازی غیراصولی خسارت‌های زیادی به بار آورد که برای حل این قبیل مشکلات چندین راه‌کار وجود دارد.

سعی کنید API خود را بر روی سروری جداگانه و متفاوت از دیتابیسی که به آن متصل می‌شود راه‌اندازی کنید. همچنین اگر به کاربران خود امکان اضافه کردن و یا ویرایش اطلاعات را نیز می‌دهید، خود را برای مقابله با هر نوعی از Injection آماده کنید که برای کسب‌ اطلاعات بیشتر،‌ توصیه می‌کنیم به مقالات زیر مراجعه نمایید:

- آشنایی با مفهوم SQL Injection در زبان PHP
- XPath Injection: آشنایی با آسیب‌پذیری داکیومنت‌های XML

یکی دیگر از حملات سایبری خطرناک Distributed Denial of Service یا به اختصار DDoS نام دارد که نیاز دارید تا راه‌کارهای حفاظتی برای مقابله با این حملات را نیز رعایت کنید که برای این منظور توصیه می‌کنیم به مقالهٔ DDoS (دیداس) چیست؟ مراجعه نمایید.

 

[☾♔TALAYEH_A♔☽]

نکاتی که در ارتباط با انتخاب API ها می بایست مد نظر قرار دهیم


آنچه در این آموزش قرار است مورد بررسی قرار دهیم، نکاتی است که در حین انتخاب APIها می بایست مد نظر قرار داد. همواره می بایست در انتخاب APIها موارد زیر را مد نظر قرار دهیم:

- در دسترس بودن داده های مورد نیاز: API سرویسی که قصد استفاده از آن را داریم می بایست منطبق بر نیازهای ما باشد و همان اطلاعاتی که نیاز داریم را در اختیار ما قرار دهد که در غیر این صورت، استفاده از API کار بیهوده‌ای خواهد بود چرا که ما به هدف خود نرسیده ایم.

- معتبر بودن سرویس: می بایست Uptime (آپ تایم یا زمان در دسترس بودن) سرویس یا سایت بسیار بالا باشد. به عبارت دیگر، سرویس مد نظر می بایست تحت هر شرایطی آپدیت باشد تا بتواند از طریق API اش، اطلاعات لحظه‌ای را در اختیار سرویس شما قرار دهد.

- مستندات: پیش از استفاده از API، به مستندات آن رجوع کرده و آن‌ها را مطالعه کنید تا مطمئن شوید که همه چیز به وضوح توضیح داده است چرا که برای استفاده از API، پیش از هر چیز می بایست نحوه ی کار با آن را فرا بگیرید. پس سهولت استفاده از API به منزله ی عاملی تعیین کننده است.

- پشتیبانی: گاهی اوقات همه چیز طبق روال پیش نرفته و شرایط غیر منتظره ای ایجاد می‌گردد که حتی مستندات قوی آن API هم پاسخگوی شما نخواهند بود که در چنین شرایطی پشتیبانی شرکت تولید کننده ی آن API تنها روزنه ی امید توسعه دهندگان خواهد بود.

- هزینه: بسیاری از API ها به رایگان در دسترس توسعه دهندگان قرار می‌گیرند اما این رایگان بودن تا جایی ادامه می‌یابد که پس از آن، توسعه دهنده می بایست هزینه کند. پیش از استفاده از یک API، پلن های آن را به دقت مورد مطالعه قرار دهید چرا که ممکن است اقدام به استفاده از یک API کنید و تا زمانی که شما کار زیادی با آن API ندارید همه چیز رایگان است اما به محض این که سرویس شما مخاطبین خاص خود را پیدا می‌کند و در نتیجه نیاز شما به آن API بیشتر می گردد، شرکت مذکور از ارائه خدمات بیشتر به صورت رایگان به شما سر باز زده و شما را ملزم به پرداخت هزینه می کند!

 

[☾♔TALAYEH_A♔☽]

آشنایی با مفهوم Screen Scraping


اکنون قصد داریم فرض کنیم که اصلاً چیزی به عنوان API وجود خارجی نداشت. در چنین شرایطی توسعه دهندگان چگونه می توانستند از داده‌های سایر سایت‌ها یا سرویس ها استفاده کنند؟ در پاسخ به چنین سؤالی بایستی گفت که توسعه دهندگان می بایست فرایندهایی توسعه دهند تا به جستجوی وب سایت مد نظر پرداخته، داده‌ها را کپی کرده و برای استفاده در آینده در فضای خاصی ذخیره سازند. به این روش جمع آوری اطلاعات در دنیای برنامه نویسی Screen Scraping یا Web Scraping گفته می شود.

از جمله مزایای Screen Scraping نسبت به دریافت اطلاعات از طریق API می‌توان به این نکته اشاره کرد که API ها معمولاً محدودیت‌هایی را در نحوه ی استفاده از سرویس ها اعمال می‌کنند اما این در حالی است که در روش دوم، توسعه‌دهنده با هیچ گونه محدودیت خاصی رو به رو نخواهد بود (البته همیشه استثناء هایی وجود دارد!)

با این حال، Screen Scraping نقاط ضعفی هم دارا است. به طور مثال، فرض کنیم که می‌خواهیم از سایت الف که آمار طلا و سکه را به صورت لحظه‌ای در اختیار کاربران قرار می‌دهد، داده استخراج کرده و در سایت ب نمایش دهیم. در چنین صورتی، می بایست مکان دقیق قرار گیری نرخ طلا و سکه را مشخص کنیم. مثلا، در صفحه ی اصلی سایت الف، در پاراگراف دوم، خط سوم و واژه ی چهارم قیمت سکه ی تمام بهار آزادی چاپ شده است. کدهایی که ما در سایت ب نوشته‌ایم تا اقدام به Screen Scraping کنند، دقیقاً به سراغ آن مکان رفته تا قیمت را استخراج کنند اما متأسفانه سایت الف در ساختار سایت تغییراتی ایجاد کرده و محل قرارگیری نرخ طلا و سکه را تغییر داده و این بار قیمت ها در پاراگراف سوم هستند. حال از این پس هر داده‌ای که ما استخراج کنیم اشتباه خواهد بود و این یک فاجعه است! علاوه بر این، بسیاری از سایت‌ها هستند -مثل سکان آکادمی- که به هیچ وجه اجازه ی استخراج داده‌ها را به سایر توسعه دهنندگان نمی‌دهند و در صورت نقض قوانین سایت، سایت دیگر می بایست پاسخگوی نقض قوانین سایت باشد.

 

[☾♔TALAYEH_A♔☽]

آشنایی با مفهوم RESTful API


یکی از بخش‌های لاینفک وب مدرن، ای پی آی ها، به کارگیری از آن ها، توسعه ی آن‌ها و مهم از همه معماری RESTful API است که هر توسعه‌دهنده ی وب اپلیکیشنی، باید با ساز و کار آن آشنایی داشته باشد که در این آموزش قصد داریم نگاهی کلی به مفهوم رستفول ای پی آی داشته باشیم.

REST مخفف واژگان Representational State Transfer است که از سال ۲۰۰۵ در وب شناخته شد که در ظاهر کمی گیج‌کننده به نظر می رسد، اما با کمی توضیح، می‌توان این مفهوم در ظاهر پیچیده را رمزگشایی کرد!

اگر خیلی ساده بخواهیم به این قضیه نگاه کنیم، REST عبارت است از راه کارها و روش‌هایی که با استفاده از آن‌ها می‌توان به رد و بدل دیتا از طریق شبکه پرداخت. به عبارت دیگر، REST راهی ساده به منظور سازماندهی تعاملات مابین سیستم‌های مجزا از یکدیگر می باشد.

در مقابل REST، پروتکل SOAP که مخفف واژگان Simple Object Access Protocol است قرار دارد که از طریق آن می‌توان به رد و بدل دیتا از طریق شبکه در قالب وب سرویس های مختلفی با فرمت XML پرداخت.

API هم مخفف واژگان Application Programming Interface است که دربرگیرنده ی متدهایی برای ارتباط با سایر لایبرری ها یا اپلیکیشن ها است.

حال اگر این اصطلاحات در کنار یکدیگر قرار دهیم و چیزی تحت عنوان RESTful API بسازیم، منظورمان ساز و کارهایی برای ارتباط با سایر سرویس ها با استفاده از معماری خاصی است. معماری REST دارای یکسری ویژگی‌ها است که شاخص ترین آن‌ها عبارتند از:
- ثبات و یکنواختی این معماری در جای جای API
- عدم برخورداری از سشن در سمت سرور
- به کارگیری از کدهای وضعیت اچ تی تی پی
- استفاده از یو آر ال ها برای مشخص ساختن مسیرهای مد نظر
- اعمال کوئری ها در یو آر ال به جای هدر پروتکل اچ تی تی پی

با این تفاسیر، RESTful API ها به خدمت توسعه دهندگان وب آمده‌اند تا فرایند توسعه ی وب، ایجاد تجربه ی کاربری بهتر، سهولت در استفاده از ای پی آی ها و نقل و انتقال داده‌ها از طریق پروتکل اچ تی تی پی را امکان‌پذیر سازند.

علاوه بر این، توجه داشته باشیم که REST بیش از آنکه پروتکل باشد، یکسری راهنما، اصول و قواعدی است که با استفاده از آن‌ها می‌توانیم به برقراری ارتباط مابین منابع مختلف بپردازیم.

حال برای درک بهتر این موضوع، مثالی عملی می زنیم. فرض کنیم که قصد داریم از ای پی آی شبکه ی اجتماعی توییتر برای نشان دادن محبوب‌ترین توییت ها در وب سایت خود استفاده کنیم. در چنین شرایطی، ما بدون آن که دسترسی به سرور این شبکه ی اجتماعی داشته باشیم، قادر خواهیم بود تا دیتای مد نظر خود را گرفته و در معرض دید کاربرانمان قرار دهیم. معمولاً سرویس هایی که API در اختیار توسعه دهندگان قرار می دهند، دیتای مد نظر را در فرمت JSON در اختیار آن‌ها قرار می‌دهند البته برخی سرویس ها هم هستند که از فرمت XML استفاده می کنند.

HTTP چیست؟
پیش از نگاهی عمیق‌تر به رستفول ای پی آی، باید با مفهوم اچ تی تی پی آشنا شویم. به طور کلی، HTTP به پروتکلی اشاره دارد که از آن طریق می‌توان در بستر وب به نقل و انتقال دیتا پرداخت. در اینجا منظور از پروتکل هم یکسری اصول و قواعدی است که مشخص می‌سازند چه پیام‌هایی قابل انتقال هستند و کدام یک از آن‌ها باید در پاسخ به دیگری ارسال شوند. برای اجرایی شدن پروتکل اچ تی تی پی، نیاز به یک کلاینت و یک سرور داریم؛ معمولاً منظور از کلاینت، مرورگری است که با استفاده از آن وبگردی می‌کنید که این مرورگر معمولاً آغاز کننده ی ارتباط از طریق این پروتکل است.

پیام‌هایی از جنس اچ تی تی پی حاوی دو بخش هستند که یکی Body نام دارد و دیگری Header. دیتایی که شما قصد دارید از طریق مرورگر خود برای سرور ارسال کنید -مثلا نام کاربری و رمزعبور که وارد فرم لاگین می کنید- در بخش Body قرار می گیرند. Header هم دربرگیرنده ی یکسری متادیتا مثل Encoding، متدهای اچ تی تی پی و غیره است که این متادیتا ها مشخص کننده ی این مسأله هستند که دیتای قرار گرفته در Body به شکل می بایست هندل شود.

در صورتی که از گوگل کروم استفاده می کنید، با فشردن هم‌زمان کلیدهای Ctrl + Shift + J می‌توانید پنجره ی Chrom Developer Tools را باز کرده وارد تب Network شوید و همان‌طور که به گشت زنی در وب می پردازید، می‌توانید جزئیات هدر و بادی پروتکل HTTP را رصد کنید. در صورتی هم که از مرورگر فایرفاکس استفاده می کنید، با نصب افزونه ی Firebug می‌توانید به چنین قابلیتی دست یابید.

راه‌کار دیگری که از آن طریق می‌توانید با درخواست های اچ تی تی پی آشنا شوید، ابزاری است تحت عنوان cURL که یک ابزار کامند لاین است که در اکثر سیستم عامل های مطرح مثل ویندوز، مک و لینوکس در دسترس است. به طور مثال، پس از نصب این ابزار در لینوکس، می‌توانید در ترمینال دستور زیر را تایپ کنید:

curl -v سکان آکادمی :: آموزش برنامه نویسی
و خواهید دید که محتوای صفحه ی هوم پیج سکان آکادمی در ترمینال لود می‌شود (علاوه بر کامند لاین بودن cURL، از آن می‌توان به عنوان یک لایبرری برای اکثر زبان‌های برنامه نویسی من جمله PHP نیز استفاده کرد.)

HTTP Verbs
حال ممکن است این سؤال پیش بیاید که چگونه می‌توان اکشن یا عملکردی برای درخواستی که از طریق پروتکل اچ تی تی پی ارسال می‌کنیم تعریف نماییم؟ در پاسخ به این سؤال باید گفت که در اینجا باید با مفهومی تحت عنوان HTTP Verbs آشنا شویم که نام دیگرش HTTP Methods است که پیش از این به طور مفصل در مورد آن ها صحبت کرده ایم. هر درخواست از جنس اچ تی تی پی، حاوی متدی است که در بخش هدر قرار می گیرد. به طور مثال:

GET / HTTP/1.1
این دستور حاکی از آن است که متد GET که پیش از این با آن آشنا شدیم برای فراخوانی اطلاعات مورد استفاده قرار گرفته است. به عبارت دیگر، متدهای اچ تی تی پی به سرور دستور می‌دهند که با دیتایی که از طریق یو آر آل برای سرور ارسال می‌کنید چه کاری انجام دهند؛ مثلاً آیا رکورد خاصی را حذف کنند یا آن را آپدیت کنند و …
برای به کارگیری از RESTful API، چهار متد پیش رو داریم که عبارتند از:
- GET: برای دریافت یک آبجت
- POST: برای ساخت و ارسال یک آبجکت
- PUT: برای تغییر و جایگزین کردن یک آبجکت
- DELETE: برای حذف یک آبجکت

که در اینجا منظور از آبجکت، یک درخواست یا کوئری به سرور است. اکثر ای پی آی های تحت وب که اطلاعاتی را به رایگان در اختیار توسعه دهندگان قرار می‌دهند معمولاً فقط و فقط امکان استفاده از متد GET را به توسعه‌دهنده می‌دهند تا دیتای خاصی را از سرور ارائه دهنده ای پی آی مد نظر دریافت کنند چرا که این متد اصلا تهدیدی برای سرویس ارائه دهنده ی API محسوب نمی گردد زیرا توسعه دهنده فقط می تواند اصطلاحا Read کند و اجازه ی Write کردن روی دیتابیس را ندارد.

برخی از وب اپلیکیشن هایی هم که امکان استفاده از سایر متدها همچون PUT و DELETE را به توسعه دهندگان می دهند، پیش از عملی ساختن هر گونه درخواستی از طرف توسعه دهنده، اقدام به تصدیق اطلاعات توسعه‌دهنده (Authentication) می‌کنند که چنین قابلیتی نیاز به ثبت نام در سرویس مد نظر، گرفتن یک شناسه ی اختصاصی و … دارد.

متد GET ساده‌ترین و پرکاربردترین متد استفاده شده در پروتکل اچ تی تی پی است. به طور کلی، هر وقت که شما روی لینکی در سکان آکادمی کلیک می کنید، این متد از طریق هدر پروتکل اچ تی تی پی برای سرور این سایت ارسال می شود. این متد به سرور دستور می‌دهد تا اطلاعات مرتبط با آدرس لینکی که روی آن کلیک شده است را برای مرورگر شما ارسال کند.

پیش از این گفتیم که پروتکل اچ تی تی پی دارای دو بخش هدر و بادی است؛ هدر حاوی متادیتاها است که صرفاً می‌تواند حاوی Plain Text یا «متن خالی» باشد که با فرمت خاصی نوشته می‌شوند اما بادی این پروتکل می‌تواند حاوی دیتایی با هر فرمتی باشد. از متن خالی گرفته تا تصاویر، کدهای اچ تی ام ال، اکس ام ال، جسون و غیره.

زمانی که مرورگر درخواستی را برای سرور ارسال می کند، اگر همه چیز به درستی اتفاق بیافتد، سرور پاسخی را برای مرورگر (کلاینت) ارسال می کند. حال برای اینکه این پاسخ قابل درک برای مرورگر باشد، باید در بخش هدر پاسخ سرور، Content Type یا «نوع محتوا» بادی مشخص شود که این کار در هدر پاسخ صورت می گیرد:

Content-Type: text/html
در مثال فوق، پاسخ ارسال شده از سمت سرور در قالب فایل اچ تی ام ال ارسال شده است.