آموزش HTTP Request در n8n؛ اتصال به API و ارسال و دریافت داده‌ها

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

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

برای پیاده‌سازی این فرایندها در n8n، یکی از مهم‌ترین ابزارها نود HTTP Request است. این نود به شما اجازه می‌دهد درخواست HTTP بسازید، روش احراز هویت را تنظیم کنید، پارامترها و داده‌های موردنیاز را ارسال کنید و پاسخ سرویس مقصد را در مراحل بعدی Workflow به کار ببرید.

در این مقاله، از مفاهیم پایه شروع می‌کنیم و مرحله‌به‌مرحله یاد می‌گیریم چگونه HTTP Request را تنظیم کنیم، اطلاعات را از API دریافت کنیم، داده بفرستیم و خطاهای متداول را برطرف کنیم.

HTTP Request در n8n چیست؟

HTTP Request یک نود داخلی در n8n است که برای ارسال درخواست به یک آدرس اینترنتی یا سرویس قابل دسترس از طریق HTTP و HTTPS استفاده می‌شود.

فرض کنید یک فروشگاه اینترنتی دارید و می‌خواهید اطلاعات یک محصول را از API دریافت کنید. اگر سرویس مقصد یک API استاندارد ارائه کرده باشد، می‌توانید آدرس آن را در HTTP Request قرار دهید و روش درخواست را مشخص کنید.

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

برخی کاربردهای HTTP Request عبارت‌اند از:

• دریافت اطلاعات از APIهای عمومی و اختصاصی
• ارسال اطلاعات فرم‌ها به یک سرویس خارجی
• ایجاد یا به‌روزرسانی اطلاعات در یک نرم‌افزار
• دریافت وضعیت سفارش، پرداخت یا ارسال کالا از API مربوطه
• اتصال به سرویس‌های هوش مصنوعی
• دریافت اطلاعات از سامانه‌های مدیریت مشتریان یا CRM
• ارسال اطلاعات به سرویس پیامکی یا سامانه اعلان، در صورت پشتیبانی API آن سرویس
• دریافت اطلاعات از API و ذخیره آن در PostgreSQL

نکته مهم این است که HTTP Request خودش سرویس مقصد را ایجاد نمی‌کند؛ بلکه با API موجود ارتباط برقرار می‌کند. برای استفاده از آن باید آدرس API، روش درخواست و در صورت نیاز اطلاعات احراز هویت را بدانید.

تفاوت HTTP Request و Webhook در n8n چیست؟

HTTP Request و Webhook هر دو برای ارتباط بین سیستم‌ها استفاده می‌شوند، اما نقش آن‌ها یکسان نیست.

در Webhook، یک سیستم خارجی درخواستی به آدرس n8n ارسال می‌کند و این درخواست می‌تواند آغازگر یک Workflow باشد.

در HTTP Request، خود n8n در جریان اجرای Workflow به یک API درخواست ارسال می‌کند.

برای مثال، فرض کنید کاربر در سایت شما ثبت‌نام می‌کند. سایت می‌تواند با استفاده از Webhook اطلاعات ثبت‌نام را به n8n بفرستد. سپس n8n با HTTP Request به API یک سرویس دیگر درخواست ارسال کند تا اطلاعات کاربر در آن سرویس ثبت شود.

در بسیاری از پروژه‌های واقعی، این دو نود در کنار یکدیگر استفاده می‌شوند.

پیش‌نیازهای استفاده از HTTP Request

پیش از ساخت اولین درخواست، بهتر است چند مفهوم ساده را بشناسید.

API: رابطی است که به برنامه‌ها اجازه می‌دهد طبق قوانین مشخص با یک سرویس ارتباط برقرار کنند.

Endpoint: آدرس مشخصی از API است که عملیاتی مانند دریافت فهرست کاربران یا ثبت سفارش را انجام می‌دهد.

HTTP Method: نوع عملیات درخواستی را مشخص می‌کند؛ مانند GET برای دریافت اطلاعات یا POST برای ارسال داده.

Header: اطلاعات تکمیلی درخواست است؛ مانند نوع محتوای ارسالی یا اطلاعات احراز هویت.

Body: محتوای اصلی درخواست است که معمولاً در درخواست‌هایی مانند POST یا PUT برای ارسال داده استفاده می‌شود.

Response: پاسخی است که سرور مقصد پس از دریافت درخواست برمی‌گرداند.

بسیاری از APIها اطلاعات را در قالب JSON دریافت و ارسال می‌کنند؛ بنابراین آشنایی اولیه با ساختار JSON برای کار با HTTP Request مفید است.

آموزش ساخت اولین HTTP Request در n8n

برای شروع، یک Workflow جدید در n8n ایجاد کنید.

مرحله اول: افزودن نود HTTP Request

در محیط طراحی Workflow، روی افزودن نود کلیک کنید و عبارت HTTP Request را جست‌وجو کنید.

پس از انتخاب نود، تنظیمات درخواست نمایش داده می‌شود. در این قسمت می‌توانید متد HTTP، آدرس مقصد، روش احراز هویت و سایر گزینه‌ها را مشخص کنید.

مرحله دوم: تنظیم Method و URL

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

مقدار Method را روی GET قرار دهید و URL زیر را وارد کنید:

https://jsonplaceholder.typicode.com/posts/1

این API برای آزمایش و آموزش در دسترس است و اطلاعات نمونه برمی‌گرداند.

در این درخواست، قصد داریم اطلاعات یک پست نمونه را دریافت کنیم. چون درخواست فقط برای دریافت اطلاعات است، نیازی به ارسال Body نداریم.

مرحله سوم: اجرای درخواست

پس از تنظیم Method و URL، نود را اجرا کنید.

اگر ارتباط با سرویس برقرار شود، باید پاسخی شبیه نمونه زیر دریافت کنید:

{

  "userId": 1,

  "id": 1,

  "title": "sunt aut facere repellat provident occaecati",

  "body": "quia et suscipit..."

}

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

در این مثال، شناسه پست از طریق فیلد زیر قابل دسترسی است:

{{ $json.id }}

عنوان پست نیز از این مسیر خوانده می‌شود:

{{ $json.title }}

در n8n، Expressionها به شما کمک می‌کنند مقادیر خروجی نودهای قبلی را به‌صورت پویا در تنظیمات نودهای بعدی استفاده کنید.

آشنایی با متدهای HTTP

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

متد GET

از GET معمولاً برای دریافت اطلاعات استفاده می‌شود.

برای مثال، اگر API مقصد امکان دریافت اطلاعات یک محصول را داشته باشد، ممکن است چنین آدرسی ارائه کند:

https://api.example.com/products/125

در این مثال، 125 شناسه محصول است و دامنه و مسیر صرفاً نمونه هستند.

متد POST

از POST معمولاً برای ارسال داده به سرویس مقصد استفاده می‌شود. این متد ممکن است برای ایجاد یک رکورد، ثبت درخواست یا اجرای یک عملیات کاربردی باشد.

برای مثال، یک API فرضی ممکن است اطلاعات محصول را در قالب JSON دریافت کند.

متد PUT و PATCH

این متدها معمولاً برای به‌روزرسانی اطلاعات استفاده می‌شوند. رفتار دقیق هرکدام به طراحی API مقصد بستگی دارد.

در بسیاری از APIها، PUT برای جایگزینی یا به‌روزرسانی یک منبع و PATCH برای اعمال تغییرات محدود به کار می‌رود؛ اما همیشه باید مستندات سرویس مقصد را بررسی کنید.

متد DELETE

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

نکته مهم این است که انتخاب متد به‌تنهایی عملیات را تعیین نمی‌کند؛ Endpoint و قوانین API نیز باید با آن سازگار باشند.

ارسال Query Parameters به API

برخی APIها اطلاعات موردنیاز خود را از طریق پارامترهای URL دریافت می‌کنند. به این مقادیر Query Parameters گفته می‌شود.

برای مثال، فرض کنید API مقصد امکان جست‌وجوی محصولات را فراهم کرده است و انتظار دارد نام محصول در پارامتری با عنوان search ارسال شود.

آدرس درخواست ممکن است به این شکل باشد:

https://api.example.com/products?search=phone

در HTTP Request می‌توانید به‌جای نوشتن دستی پارامترها در URL، گزینه مربوط به ارسال Query Parameters را فعال کنید.

سپس پارامتر زیر را اضافه کنید:

• Name: search
• Value: phone

اگر مقدار پارامتر از نود قبلی دریافت می‌شود، می‌توانید به‌جای مقدار ثابت از Expression استفاده کنید.

برای نمونه:

{{ $json.search }}

در این حالت، مقدار پارامتر از فیلد search در داده ورودی نود خوانده می‌شود.

نام پارامترها و ساختار آن‌ها باید دقیقاً مطابق مستندات API مقصد باشد. برای مثال، یک API ممکن است از page و limit استفاده کند، درحالی‌که سرویس دیگری پارامترهایی با نام متفاوت داشته باشد.

ارسال Header در HTTP Request

Headerها برای ارسال اطلاعات تکمیلی به سرور مقصد استفاده می‌شوند.

یکی از کاربردهای رایج Header، مشخص‌کردن نوع محتوای درخواست است. برای مثال، هنگام ارسال JSON معمولاً از Header زیر استفاده می‌شود:

Content-Type: application/json

بسیاری از تنظیمات HTTP Request هنگام انتخاب نوع Body به‌صورت خودکار Header مناسب را مدیریت می‌کنند؛ بنابراین همیشه لازم نیست آن را به‌صورت دستی اضافه کنید.

کاربرد دیگر Header، ارسال اطلاعات احراز هویت است. برای نمونه، برخی APIها انتظار دارند توکن دسترسی در Header زیر قرار بگیرد:

Authorization: Bearer YOUR_ACCESS_TOKEN

عبارت YOUR_ACCESS_TOKEN در این مثال مقدار واقعی نیست و باید با توکن معتبر سرویس مقصد جایگزین شود.

برای افزودن Header در HTTP Request:

1. گزینه ارسال Header را فعال کنید.
2. نام Header را در بخش Name وارد کنید.
3. مقدار مورد انتظار API را در بخش Value قرار دهید.
4. درخواست را آزمایش کنید.

اگر Header مربوط به احراز هویت است، بهتر است اطلاعات محرمانه را در Credential مناسب نگهداری کنید و از قرار دادن آن‌ها به‌صورت ثابت در گردش‌کارهای قابل اشتراک‌گذاری خودداری کنید.

ارسال JSON در HTTP Request

در بسیاری از APIها، اطلاعات از طریق Body و در قالب JSON ارسال می‌شوند.

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

{

  "name": "Ali",

  "email": "ali@example.com",

  "role": "customer"

}

برای تنظیم این درخواست در n8n:

1. متد را روی POST قرار دهید.
2. URL مربوط به Endpoint مقصد را وارد کنید.
3. گزینه ارسال Body را فعال کنید.
4. نوع Body را بر اساس نیاز API روی JSON قرار دهید.
5. فیلدهای موردنیاز را اضافه کنید.
6. در صورت نیاز، احراز هویت را تنظیم کنید.
7. نود را اجرا کنید و پاسخ را بررسی کنید.

اگر داده‌ها از نود قبلی می‌آیند، می‌توانید مقادیر را به کمک Expression وارد کنید.

برای مثال، اگر خروجی نود قبلی شامل فیلدهای name و email باشد، مقادیر Body را می‌توانید از این عبارت‌ها بگیرید:

{{ $json.name }}

{{ $json.email }}

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

آموزش احراز هویت API در n8n

بسیاری از APIها برای جلوگیری از دسترسی غیرمجاز، به اطلاعات احراز هویت نیاز دارند.

روش احراز هویت به سرویس مقصد بستگی دارد. HTTP Request در n8n از روش‌های مختلفی پشتیبانی می‌کند و برای APIهایی که به اعتبارنامه نیاز دارند، بهتر است از بخش Credentials استفاده کنید.

روش اول: بدون احراز هویت

برخی APIهای عمومی برای خواندن اطلاعات نیازی به توکن یا رمز عبور ندارند.

در این حالت، اگر API واقعاً درخواست ناشناس را پشتیبانی کند، می‌توانید درخواست را بدون تنظیم Authentication ارسال کنید.

روش دوم: Basic Auth

در این روش، نام کاربری و رمز عبور برای احراز هویت استفاده می‌شوند.

اگر API مقصد از Basic Auth پشتیبانی کند، یک Credential متناسب ایجاد کنید و اطلاعات موردنیاز را در آن وارد کنید.

روش سوم: Header Auth یا API Key

برخی سرویس‌ها یک کلید اختصاصی را در Header درخواست دریافت می‌کنند.

برای مثال، API ممکن است Header زیر را انتظار داشته باشد:

X-API-Key: YOUR_API_KEY

نام Header و روش ارسال کلید باید مطابق مستندات سرویس مقصد باشد.

روش چهارم: Bearer Token

در بسیاری از APIها، توکن دسترسی در Header مربوط به Authorization ارسال می‌شود.

نمونه:

Authorization: Bearer YOUR_ACCESS_TOKEN

توکن باید معتبر باشد و ممکن است تاریخ انقضا یا محدودیت دسترسی داشته باشد.

روش پنجم: OAuth2

برخی سرویس‌ها از OAuth2 برای اعطای دسترسی استفاده می‌کنند. در این حالت باید اطلاعات اتصال، Client ID، Client Secret و سایر پارامترهای موردنیاز را مطابق مستندات سرویس تنظیم کنید.

در n8n، در صورت پشتیبانی سرویس از Credential اختصاصی، استفاده از همان نوع اعتبارنامه معمولاً مدیریت اتصال را ساده‌تر می‌کند.

نکته امنیتی: هرگز توکن واقعی یا رمز عبور را در مقاله، اسکرین‌شات عمومی، مخزن کد یا خروجی قابل مشاهده برای کاربران منتشر نکنید. برای محیط عملیاتی، از Credentialهای امن و حداقل سطح دسترسی موردنیاز استفاده کنید.

چگونه پاسخ API را در n8n پردازش کنیم؟

پس از اجرای HTTP Request، خروجی نود در اختیار مراحل بعدی Workflow قرار می‌گیرد.

فرض کنید API اطلاعات یک سفارش را به شکل زیر برمی‌گرداند:

{

  "id": 125,

  "status": "paid",

  "amount": 850000

}

می‌توانید مقدار وضعیت سفارش را با Expression زیر بخوانید:

{{ $json.status }}

و مبلغ را از این مسیر دریافت کنید:

{{ $json.amount }}

سپس با استفاده از نودهایی مانند IF، Edit Fields یا PostgreSQL، اطلاعات را بررسی یا ذخیره کنید.

برای مثال، اگر قصد دارید فقط سفارش‌هایی را پردازش کنید که وضعیت آن‌ها paid است، می‌توانید بعد از HTTP Request یک نود IF قرار دهید و مقدار status را بررسی کنید.

در این روش، داده‌ها براساس نتیجه درخواست به مسیرهای مختلف گردش‌کار هدایت می‌شوند.

تنظیم Response Format

برخی APIها پاسخ JSON برمی‌گردانند، اما بعضی سرویس‌ها متن ساده یا فایل ارائه می‌کنند.

در تنظیمات HTTP Request می‌توانید قالب پاسخ را مطابق نیاز انتخاب کنید. حالت Autodetect معمولاً برای تشخیص خودکار قالب مناسب است. گزینه‌های دیگر ممکن است شامل JSON، Text یا File باشند.

اگر پاسخ سرویس به‌صورت فایل است، باید تنظیمات مربوط به دریافت داده باینری را بررسی کنید. اگر پاسخ JSON است، ساختار خروجی را بررسی کنید تا بتوانید فیلدها را در مراحل بعدی به‌درستی بخوانید.

دریافت کد وضعیت و Headerهای پاسخ

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

در HTTP Request گزینه‌ای برای دریافت اطلاعات کامل پاسخ، شامل Headerها و کد وضعیت وجود دارد. در صورت نیاز آن را فعال کنید و سپس خروجی نود را بررسی کنید.

این قابلیت برای عیب‌یابی APIها و تشخیص تفاوت بین پاسخ‌های موفق و خطادار مفید است.

دریافت اطلاعات از چند صفحه با Pagination

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

به این روش صفحه‌بندی یا Pagination گفته می‌شود.

فرض کنید API از پارامترهای page و limit پشتیبانی می‌کند. ممکن است درخواست اول اطلاعات صفحه اول را برگرداند و برای دریافت اطلاعات بیشتر لازم باشد شماره صفحه را افزایش دهید.

HTTP Request در n8n گزینه Pagination دارد که به شما اجازه می‌دهد درخواست‌ها را مطابق الگوی صفحه‌بندی API تکرار کنید.

روش تنظیم آن به API مقصد بستگی دارد. برخی سرویس‌ها از شماره صفحه استفاده می‌کنند، بعضی از آن‌ها پارامتر Offset دارند و برخی دیگر آدرس صفحه بعد یا یک Cursor را در پاسخ برمی‌گردانند.

برای تنظیم Pagination:

1. ابتدا یک درخواست ساده به API ارسال کنید.
2. ساختار پاسخ و روش صفحه‌بندی را در مستندات سرویس بررسی کنید.
3. در تنظیمات HTTP Request، بخش Add Option را باز کنید.
4. گزینه Pagination را اضافه کنید.
5. روش مناسب را انتخاب کنید.
6. پارامتر یا آدرس صفحه بعد را مطابق ساختار API تعریف کنید.
7. برای تعداد درخواست‌ها و محدودیت‌های سرویس، سقف مناسبی در نظر بگیرید.

اگر API از شماره صفحه استفاده می‌کند، ممکن است لازم باشد مقدار پارامتر page در هر درخواست افزایش یابد. در Expressionهای Pagination، متغیر $pageCount تعداد صفحه‌های دریافت‌شده را در اختیار قرار می‌دهد؛ مقدار اولیه آن صفر است.

برای نمونه، اگر API از صفحه‌بندی یک‌مبنا استفاده کند، می‌توان از عبارت زیر برای شماره صفحه استفاده کرد:

{{ $pageCount + 1 }}

این تنظیم فقط زمانی مناسب است که API واقعاً از پارامتر page با شروع از عدد یک استفاده کند.

هنگام دریافت داده‌های زیاد، حتماً محدودیت تعداد درخواست‌ها، فاصله بین درخواست‌ها و سیاست‌های Rate Limit سرویس مقصد را رعایت کنید. تنظیم نادرست Pagination می‌تواند باعث ارسال تعداد زیادی درخواست غیرضروری شود.

استفاده از cURL برای تنظیم سریع HTTP Request

گاهی مستندات API یک نمونه درخواست cURL ارائه می‌کنند. در این شرایط، لازم نیست همه تنظیمات را از ابتدا به‌صورت دستی وارد کنید.

HTTP Request در n8n قابلیتی برای Import cURL دارد که می‌تواند بسیاری از تنظیمات درخواست را از روی دستور نمونه وارد کند.

برای استفاده از این قابلیت:

1. نود HTTP Request را باز کنید.
2. گزینه Import cURL را انتخاب کنید.
3. دستور cURL ارائه‌شده در مستندات API را وارد کنید.
4. عملیات Import را انجام دهید.
5. تنظیمات واردشده را بررسی کنید.
6. اطلاعات محرمانه را به Credential مناسب منتقل کنید.
7. درخواست را در محیط تست اجرا کنید.

برای مثال، ممکن است مستندات یک API دستور زیر را ارائه کنند:

curl -X GET \

  "https://jsonplaceholder.typicode.com/posts/1" \

  -H "Accept: application/json"

با واردکردن این دستور می‌توانید بخشی از تنظیمات درخواست را سریع‌تر آماده کنید.

بااین‌حال، همیشه نتیجه Import را بررسی کنید؛ به‌ویژه اگر درخواست شامل توکن، Headerهای سفارشی یا مقادیر حساس باشد. همچنین مقادیر واردشده از cURL ممکن است به‌صورت رشته در تنظیمات قرار بگیرند، بنابراین نوع داده‌ها را در صورت نیاز بررسی کنید.

مدیریت خطاهای HTTP Request

در اتصال به API، ممکن است درخواست به دلایل مختلف شکست بخورد. مدیریت صحیح خطاها باعث می‌شود گردش‌کار شما قابل‌اعتمادتر باشد.

خطای 400؛ درخواست نامعتبر

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

موارد زیر را بررسی کنید:

• نام و نوع فیلدهای Body
• پارامترهای ارسالی
• ساختار JSON
• الزامات مستندات API

خطای 401 یا 403؛ مشکل دسترسی

خطای 401 معمولاً با احراز هویت ناموفق ارتباط دارد و خطای 403 معمولاً به محدودیت دسترسی مربوط می‌شود؛ البته جزئیات به سرویس مقصد بستگی دارد.

اعتبار Credential، تاریخ انقضای توکن، سطح دسترسی و روش احراز هویت را بررسی کنید.

خطای 404؛ Endpoint پیدا نشد

در این حالت، آدرس API یا مسیر درخواست ممکن است اشتباه باشد، یا منبع موردنظر وجود نداشته باشد.

آدرس را با مستندات رسمی سرویس تطبیق دهید و مطمئن شوید شناسه یا مسیر درست است.

خطای 429؛ محدودیت تعداد درخواست‌ها

برخی APIها تعداد درخواست‌ها را در یک بازه زمانی محدود می‌کنند.

اگر با خطای 429 روبه‌رو شدید، سیاست Rate Limit سرویس را بررسی کنید و در صورت نیاز فاصله بین درخواست‌ها، تعداد درخواست‌ها یا روش تلاش مجدد را اصلاح کنید.

خطاهای 500 و سایر خطاهای سرور

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

خطای Timeout

Timeout زمانی رخ می‌دهد که درخواست در مدت مجاز به پاسخ موردانتظار نرسد.

در این شرایط، وضعیت شبکه، سرعت سرویس مقصد و تنظیمات Timeout را بررسی کنید. افزایش Timeout همیشه بهترین راهکار نیست؛ اگر سرویس بسیار کند است، بهتر است علت اصلی مشکل نیز بررسی شود.

نکته مهم درباره گزینه Never Error

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

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

نکات امنیتی هنگام اتصال به API

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

توکن‌ها را امن نگه دارید. کلیدهای API و رمزهای دسترسی را در Credentialهای مناسب نگهداری کنید و از قرار دادن آن‌ها در متن‌های عمومی یا لاگ‌های قابل مشاهده خودداری کنید.

اعتبارسنجی گواهی SSL را غیرفعال نکنید. n8n به‌صورت پیش‌فرض اعتبار گواهی SSL را بررسی می‌کند. غیرفعال‌کردن این بررسی می‌تواند امنیت ارتباط را کاهش دهد و فقط باید در شرایط محدود و با آگاهی از خطرات انجام شود.

حداقل سطح دسترسی را انتخاب کنید. اگر API برای خواندن اطلاعات کافی است، از اعتبارنامه‌ای با دسترسی حذف یا تغییر اطلاعات استفاده نکنید.

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

محدودیت درخواست‌ها را رعایت کنید. تعداد زیاد درخواست‌ها می‌تواند موجب فشار به سرویس مقصد، محدودشدن دسترسی یا افزایش هزینه شود.

اطلاعات حساس را در خروجی‌ها کنترل کنید. هنگام ثبت یا نمایش خروجی Workflow، مراقب باشید توکن‌ها، داده‌های شخصی یا اطلاعات محرمانه در دسترس افراد غیرمجاز قرار نگیرند.

یک سناریوی عملی: دریافت اطلاعات از API و ذخیره در PostgreSQL

برای درک بهتر کاربرد HTTP Request، فرض کنید می‌خواهید اطلاعاتی را از یک API دریافت و در PostgreSQL ذخیره کنید.

گردش‌کار می‌تواند شامل مراحل زیر باشد:

1. اجرای Workflow با Manual Trigger یا یک Trigger مناسب
2. ارسال درخواست به API با HTTP Request
3. بررسی پاسخ و استخراج فیلدهای موردنیاز
4. اعتبارسنجی داده‌ها
5. ذخیره اطلاعات با نود PostgreSQL
6. ثبت نتیجه یا مدیریت خطا

برای نمونه، می‌توانید با HTTP Request اطلاعات یک پست را از API عمومی دریافت کنید و سپس فیلدهای موردنیاز را به نود PostgreSQL ارسال کنید.

در این سناریو باید مطمئن شوید که جدول مقصد از قبل ایجاد شده، نوع داده‌ها با ستون‌ها مطابقت دارد و سیاست مناسبی برای جلوگیری از درج اطلاعات تکراری در نظر گرفته شده است.

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

پرسش‌های متداول درباره HTTP Request در n8n

آیا برای استفاده از HTTP Request باید برنامه‌نویسی بلد باشیم؟

برای درخواست‌های ساده، معمولاً نیازی به نوشتن کد ندارید. کافی است آدرس، متد و پارامترهای موردنیاز API را تنظیم کنید. بااین‌حال، آشنایی با HTTP، JSON و احراز هویت برای کار با APIهای پیچیده‌تر مفید است.

آیا HTTP Request در n8n فقط برای APIهای REST استفاده می‌شود؟

این نود برای ارسال درخواست‌های HTTP به سرویس‌های قابل دسترس از طریق HTTP و HTTPS کاربرد دارد. نحوه استفاده به پروتکل و قرارداد API مقصد بستگی دارد و همه سرویس‌ها الزاماً یک ساختار REST یکسان ندارند.

چگونه یک API نیازمند توکن را به n8n متصل کنیم؟

ابتدا روش احراز هویت API را از مستندات سرویس بررسی کنید. سپس Credential مناسب را در n8n بسازید و آن را در تنظیمات HTTP Request انتخاب کنید. روش دقیق به نوع احراز هویت سرویس بستگی دارد.

چرا درخواست HTTP موفق است اما اطلاعات مورد انتظار را دریافت نمی‌کنم؟

ممکن است API پاسخ موفقی برگرداند اما داده‌ها در مسیر متفاوتی قرار داشته باشند، فیلدهای مورد انتظار وجود نداشته باشند یا پارامترهای درخواست به شکل صحیح ارسال نشده باشند. خروجی کامل نود و مستندات API را بررسی کنید.

آیا می‌توان از HTTP Request برای دریافت همه رکوردهای API استفاده کرد؟

اگر API از صفحه‌بندی پشتیبانی کند، می‌توانید Pagination را در HTTP Request تنظیم کنید تا داده‌های صفحات مختلف دریافت شوند. روش تنظیم به ساختار صفحه‌بندی سرویس مقصد بستگی دارد.

آیا HTTP Request می‌تواند فایل دریافت کند؟

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

آیا می‌توان HTTP Request را با Webhook ترکیب کرد؟

بله. برای مثال، یک Webhook می‌تواند اطلاعات سفارش را دریافت کند و سپس HTTP Request جزئیات سفارش را از API فروشگاه دریافت کند یا آن را به یک سرویس دیگر بفرستد.

جمع‌بندی

نود HTTP Request در n8n یکی از ابزارهای اصلی برای اتصال گردش‌کارها به APIهای خارجی است. با استفاده از آن می‌توانید اطلاعات دریافت کنید، داده‌های جدید بفرستید، احراز هویت را تنظیم کنید و پاسخ سرویس‌ها را در مراحل بعدی Workflow پردازش کنید.

برای استفاده مؤثر از این نود، باید متد مناسب را انتخاب کنید، ساختار پارامترها و JSON را بشناسید، روش احراز هویت را مطابق مستندات API تنظیم کنید و پاسخ‌ها و خطاها را به‌درستی مدیریت کنید.

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

پس از یادگیری HTTP Request، می‌توانید آن را با Webhook، PostgreSQL و نودهای شرطی n8n ترکیب کنید و گردش‌کارهایی بسازید که اطلاعات را بین چند سیستم جابه‌جا می‌کنند و بخش زیادی از عملیات تکراری را به‌صورت خودکار انجام می‌دهند.

منابع رسمی برای مطالعه بیشتر

• مستندات HTTP Request در n8n: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/
• مستندات اعتبارنامه‌های HTTP Request: https://docs.n8n.io/integrations/builtin/credentials/httprequest/
• راهنمای Pagination در HTTP Request: https://docs.n8n.io/code/cookbook/http-request-node/pagination/
• مستندات Webhook در n8n: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/