وب سرویس پیامکی رابطی تحت وب است که به سایت یا نرم افزار اجازه می دهد ارسال پیامک و پیگیری نتیجه را از داخل کد انجام دهد. سرور برنامه، درخواست را طبق قرارداد API به سامانه پیامک می فرستد و پاسخ آن را پردازش می کند. در نتیجه، رویدادی مانند تأیید پرداخت می تواند بدون ورود دستی به پنل، فرایند اطلاع رسانی به مشتری را آغاز کند.
| نیاز پروژه | روش اتصال مناسب | نکته پیش از اجرا |
| اعلان سفارش در سایت آماده | افزونه سازگار با فروشگاه | بررسی رویدادها و نسخه افزونه |
| اتصال نرم افزار اختصاصی | فراخوانی مستقیم API از بک اند | پیاده سازی مدیریت خطا و گزارش |
| ارسال کد تأیید | سرویس مناسب پیام تراکنشی | بررسی الگو و محدودیت درخواست |
| اطلاع رسانی پرتعداد | پردازش پس زمینه و ارسال دسته ای | رعایت ظرفیت متد و کنترل تکرار |
تفاوت وب سرویس پیامکی با پنل و API پیامک
پنل پیامکی محیطی برای کاربر انسانی است؛ مدیر وارد حساب می شود، متن و گیرندگان را انتخاب می کند و گزارش می بیند. وب سرویس همین ارتباط را برای نرم افزار فراهم می کند، البته فقط در محدوده قابلیت هایی که متدهای آن ارائه می دهند. وجود یک قابلیت در پنل، لزوماً به معنی دسترسی به آن از طریق API نیست.
API مفهوم گسترده تری دارد و قرارداد ارتباط میان اجزای نرم افزاری است. وب سرویس، رابطی است که از طریق شبکه در دسترس قرار می گیرد. در خدمات پیامکی، عبارت های «api پیامک» و «وب سرویس پیامک» معمولاً برای اشاره به مسیر اتصال برنامه به سامانه استفاده می شوند؛ بنابراین معیار انتخاب، مستندات و رفتار سرویس است.
برای توسعه دهنده، پرسش اصلی این است که سرویس چه ورودی هایی می گیرد، چه پاسخ هایی برمی گرداند و چگونه می توان نتیجه را پیگیری کرد. ارسال یک درخواست موفق، شروع اتصال است. رفتار برنامه هنگام خطا، تأخیر یا تکرار رویداد تعیین می کند این اتصال در محیط واقعی چقدر قابل اتکا باشد.
اتصال سایت به سامانه پیامک چگونه کار می کند
فرض کنید مشتری هزینه سفارش را پرداخت کرده است. بک اند ابتدا نتیجه پرداخت را با منبع معتبر بررسی و وضعیت سفارش را ثبت می کند. سپس رویداد تأیید سفارش، درخواست اطلاع رسانی را ایجاد می کند؛ کلیک کاربر روی دکمه پرداخت، به تنهایی نشانه پرداخت موفق نیست.
لایه پیامک، شماره مقصد و داده های لازم را آماده می کند و درخواست احرازشده را به سرویس می فرستد. سامانه ممکن است درخواست را بپذیرد و شناسه پیام برگرداند یا آن را با خطایی مانند نامعتبر بودن ورودی رد کند. برنامه باید این پاسخ را به سفارش مرتبط کند تا پشتیبانی بتواند مسیر ارسال را پیدا کند.
پس از پذیرش، پردازش پیام و انتقال آن در مسیر مخابراتی ادامه پیدا می کند. گزارش تحویل مرحله جداگانه ای است و باید با روش مستند سرویس دریافت شود. به همین دلیل، وضعیت های «درخواست ثبت شد» و «پیامک تحویل شد» را در پایگاه داده و رابط مدیریت جدا نگه دارید.
پیش نیازهای ارسال پیامک با API
پیش از کدنویسی، سناریوی ارسال را مشخص کنید. پیامک ورود، اعلان سفارش و تبلیغ گروهی، اولویت زمانی و شرایط اجرایی یکسانی ندارند. برای نمونه، تأخیر طولانی در کد ورود می تواند آن را بی استفاده کند، اما اعلان غیرضروری را می توان تا رفع اختلال در صف نگه داشت.
- دسترسی فعال API، اعتبار کافی و روش معتبر احراز دسترسی را آماده کنید.
- خط فرستنده یا الگوی موردنیاز را با شرایط همان سرویس تطبیق دهید.
- آدرس متد، نسخه API، ساختار ورودی و نمونه پاسخ را از مستندات بردارید.
- قالب شماره مقصد، سقف گیرندگان و محدودیت نرخ درخواست را بررسی کنید.
- شماره آزمایش و روش مشاهده پاسخ و وضعیت تحویل را تعیین کنید.
در مسیر اتصال وب سرویس پیامکی پیام رسان، صفحه راهنما ثبت درخواست فعال سازی از بخش API و ساخت کلید پس از فعال شدن دسترسی را توضیح می دهد. نمونه درخواست و پاسخ نیز در همان صفحه ارائه شده است. پیش از پیاده سازی، روش ارسال معمولی یا الگویی را انتخاب و جزئیات آن را با مستندات نسخه مورد استفاده تطبیق دهید.
انتخاب روش اتصال برای پروژه های اختصاصی و آماده
اتصال مستقیم از بک اند
در پروژه اختصاصی، بهتر است ارتباط با ارائه دهنده در یک سرویس مجزا پیاده سازی شود. کنترلر سفارش یا ورود، درخواست اطلاع رسانی را به این لایه می دهد و جزئیات آدرس ها و پاسخ ها در همان لایه مدیریت می شود. این جداسازی، آزمودن خطاها و تغییر تنظیمات اتصال را ساده تر می کند.
REST یک سبک معماری است و SOAP یک پروتکل پیام رسانی؛ انتخاب میان آن ها باید با امکانات واقعی ارائه دهنده و نیاز پروژه هماهنگ باشد. در رابط های HTTP مبتنی بر JSON، نام فیلدها، نوع داده و روش احراز دسترسی را دقیق رعایت کنید. مشابه بودن ساختار دو سرویس به معنی قابل جایگزین بودن درخواست های آن ها نیست.
اتصال با افزونه
برای سایت آماده، افزونه سازگار می تواند بخش فراخوانی API را انجام دهد. بااین حال، توسعه دهنده همچنان باید زمان اجرای اعلان، نگاشت شماره موبایل و رفتار خطا را بررسی کند. نصب موفق افزونه فقط نشان می دهد بسته نصب شده است؛ سلامت ارسال را باید با یک رویداد واقعی آزمایش کرد.
در فروشگاه، بررسی کنید اعلان روی چه تغییری اجرا می شود و آیا افزونه دیگری همان پیام را می فرستد. فعال بودن هم زمان دو مسیر اطلاع رسانی می تواند مشتری را با پیام تکراری روبه رو کند. مسئولیت هر اعلان را به یک مسیر مشخص بسپارید.
اولین درخواست آزمایشی را چگونه بررسی کنیم
آزمایش را با یک شماره متعلق به تیم و متن قابل تشخیص شروع کنید. ابتدا درخواست را مستقل از منطق سفارش اجرا کنید تا خطاهای اتصال با خطاهای کسب وکار مخلوط نشوند. سپس همان اتصال را به رویداد برنامه وصل کنید و چرخه را دوباره بررسی کنید.
در یک مثال فرضی، لایه داخلی برنامه اطلاعاتی مانند recipient، template و variables را دریافت می کند. این نام ها قرارداد داخلی پیشنهادی هستند و باید هنگام فراخوانی، به فیلدهای واقعی سرویس تبدیل شوند. کلید دسترسی نیز در سرور به درخواست افزوده می شود و از ورودی مرورگر گرفته نمی شود.
برای تحلیل پاسخ، وضعیت HTTP و نتیجه تجاری داخل بدنه را جداگانه بخوانید. بعضی سرویس ها جزئیات رد شدن عملیات را در بدنه پاسخ قرار می دهند؛ بنابراین بررسی اتصال شبکه به تنهایی کافی نیست. در ارسال گروهی نیز نتیجه هر گیرنده را مطابق قرارداد متد بررسی کنید، چون ممکن است همه گیرندگان نتیجه یکسان نداشته باشند.
| نتیجه مشاهده شده | بررسی اولیه | اقدام برنامه |
| رد شدن احراز دسترسی | اعتبار کلید و فعال بودن دسترسی | توقف تکرار تا اصلاح تنظیمات |
| نامعتبر بودن ورودی | شماره مقصد و پارامترهای لازم | اصلاح داده پیش از تلاش مجدد |
| کمبود اعتبار | موجودی و وضعیت حساب | ثبت خطا و اطلاع به مسئول سرویس |
| محدودیت نرخ درخواست | ظرفیت مجاز و پاسخ سرویس | کاهش نرخ و زمان بندی مجدد |
| پایان مهلت انتظار | احتمال پذیرش درخواست قبلی | تعیین تکلیف پیش از ارسال دوباره |
| پذیرش بدون تحویل نهایی | شناسه پیام و گزارش وضعیت | پیگیری چرخه تحویل |
امنیت کلید API و مسیر ارسال
کلید API را در کد جاوااسکریپت مرورگر، مخزن عمومی یا تنظیمات قابل دانلود قرار ندهید. درخواست مرورگر باید به بک اند خودتان برسد و سرور پس از اعتبارسنجی، سرویس پیامک را فراخوانی کند. متغیر محیطی یا ابزار مدیریت اسرار، محل مناسب تری برای نگهداری کلید است.
همانطور که در cheatsheetseries.owasp.org گفته شده: «Secure REST services must only provide HTTPS endpoints.»
ترجمه: سرویس های امن REST باید فقط نقطه های پایانی HTTPS ارائه دهند. این راهنما همچنین توصیه می کند کلید API در URL قرار نگیرد، زیرا ممکن است در لاگ سرور ثبت شود.
در برنامه نیز ثبت شماره کامل، متن حساس و کد ورود را محدود کنید. برای عیب یابی، شناسه داخلی درخواست، زمان، نوع اعلان و نتیجه معمولاً مفیدترند. دسترسی کارکنان به گزارش ها را متناسب با وظیفه آن ها تنظیم کنید و برای کلید افشاشده مسیر تعویض داشته باشید.
مدیریت خطا و جلوگیری از پیامک تکراری
تکرار درخواست باید هدف مشخص داشته باشد
اگر درخواست به دلیل شماره نامعتبر رد شده باشد، تکرار همان داده مشکل را رفع نمی کند. برای اختلال موقت می توان تلاش مجدد تعریف کرد، اما تعداد و فاصله آن باید محدود باشد. پیام زمان حساس نیز باید مهلت اعتبار داشته باشد تا پس از بی استفاده شدن ارسال نشود.
طبق بخش چهارم RFC 6585 منتشرشده در آوریل 2012، کد HTTP 429 به درخواست های بیش ازحد در یک بازه زمانی اشاره دارد. پاسخ می تواند سرآیند Retry-After داشته باشد که زمان انتظار پیش از درخواست بعدی را اعلام می کند. این تعریف، سقف مجاز سرویس پیامکی شما را تعیین نمی کند؛ آن سقف باید از مستندات ارائه دهنده خوانده شود.
قطع ارتباط به معنی ارسال نشدن نیست
ممکن است سرویس پیام را پذیرفته باشد، اما پاسخ به برنامه نرسد. در این وضعیت، ارسال دوباره می تواند پیام تکراری ایجاد کند. اگر سرویس امکان استعلام با مرجع مشتری یا جلوگیری از تکرار دارد، از همان سازوکار مستند استفاده کنید؛ چنین قابلیتی را برای همه APIها فرض نکنید.
در سمت برنامه نیز برای هر اعلان، مرجع یکتایی متناسب با سفارش، نوع رویداد و گیرنده بسازید. ثبت این مرجع و کنترل هم زمانی، از ایجاد چند کار برای یک رویداد جلوگیری می کند. این کنترل محلی، ابهام درخواست پذیرفته شده ای را که پاسخ آن گم شده، به تنهایی حل نمی کند.
صف را متناسب با اهمیت پیام طراحی کنید
برای اعلان های سفارش، ثبت کار در صف پایدار می تواند وابستگی پاسخ صفحه به سرعت سرویس پیامک را کاهش دهد. اگر لازم است ثبت سفارش و ایجاد اعلان با هم حفظ شوند، الگوی Outbox را بررسی کنید؛ رویداد در همان تراکنش پایگاه داده ذخیره می شود و پردازشگر بعداً آن را ارسال می کند.
کد ورود به سیاست متفاوتی نیاز دارد. آن را پشت ارسال های تبلیغاتی معطل نکنید و پس از پایان اعتبار کنار بگذارید. در سناریوی فروشگاه نیز موفقیت ثبت سفارش را از موفقیت اعلان جدا کنید تا اختلال پیامک، وضعیت پرداخت یا سفارش را اشتباه تغییر ندهد.
گزارش تحویل و پایش اتصال
برای هر پیام، شناسه داخلی برنامه و شناسه برگشتی سرویس را کنار هم نگه دارید. اگر استعلام وضعیت در دسترس است، با فاصله مناسب و تا رسیدن به وضعیت نهایی آن را اجرا کنید. اگر سرویس وب هوک تحویل دارد، اصالت درخواست را طبق مستندات بررسی کنید و پردازش تکراری یک رویداد را کنترل کنید.
زمان ثبت رویداد، پذیرش درخواست و دریافت گزارش نهایی را جدا اندازه بگیرید. این تفکیک کمک می کند تأخیر صف داخلی را از تأخیر بیرون برنامه تشخیص دهید. وضعیت تحویل را نیز معادل خواندن پیام توسط کاربر در نظر نگیرید.
طول متن و برآورد هزینه پیامک
تعداد درخواست API، تعداد پیام منطقی و تعداد قطعه قابل محاسبه در صورتحساب، الزاماً یکسان نیستند. متن نهایی پس از جایگزینی متغیرها ممکن است طولانی تر شود؛ بنابراین فقط متن ثابت الگو را اندازه نگیرید. نام مشتری یا لینک پیگیری می تواند تعداد قطعه ها را تغییر دهد.
در مستندات طول پیام Twilio، ظرفیت تک قطعه برای GSM-7 برابر 160 نویسه و برای UCS-2 برابر ۷۰ نویسه آمده است. برای پیام چندقطعه ای UCS-2 نیز ظرفیت هر قطعه ۶۷ نویسه ذکر شده است. این اعداد، مشخصات فنی درج شده در مستندات هستند و تعرفه یا ظرفیت قراردادی همه سرویس های ایرانی محسوب نمی شوند؛ صفحه تاریخ انتشار مشخصی ندارد.
متن فارسی را با محاسبه گر یا قواعد مستند سامانه خودتان بررسی کنید. استفاده از ایموجی و برخی نویسه ها نیز به بررسی دقیق تر کدگذاری نیاز دارد. پیش از انتشار، هزینه را با متن نهایی و داده های نمونه واقعی بسنجید.
چک لیست راه اندازی در محیط اصلی
پایان پیاده سازی زمانی است که مسیر موفق و وضعیت های ناموفق، رفتار مشخص داشته باشند. نتیجه آزمایش را همراه با زمان، مرجع رویداد و شناسه پیام نگه دارید تا تیم پشتیبانی بتواند همان سناریو را بررسی کند.
- ارسال آزمایشی و دریافت گزارش نهایی را برای شماره کنترل شده بررسی کنید.
- خطاهای دسترسی، ورودی نامعتبر و کمبود اعتبار را آزمایش کنید.
- تکرار رویداد و قطع ارتباط را شبیه سازی و رفتار برنامه را مشاهده کنید.
- نبودن کلید و محتوای حساس در خروجی مرورگر و لاگ ها را کنترل کنید.
- مسئول پیگیری خطا، تمدید دسترسی و پایش اعتبار را مشخص کنید.
پرسش های متداول
آیا برای اتصال سایت به پیامک باید مودم تهیه کنیم
در اتصال به سامانه پیامکی از طریق API، برنامه با سرور ارائه دهنده ارتباط می گیرد و معمولاً به مودم GSM محلی نیاز ندارد. زیرساخت لازم در سمت شما، امکان برقراری ارتباط شبکه و اجرای کد اتصال است.
آیا وب سرویس پیامک فقط برای فروشگاه کاربرد دارد
خیر. نرم افزار نوبت دهی، سامانه آموزشی یا سیستم حسابداری نیز می تواند رویدادهای مرتبط را به اعلان پیامکی تبدیل کند. امکانات موردنیاز هر سناریو باید در API انتخابی وجود داشته باشد.
آیا یک درخواست موفق تحویل پیامک را ثابت می کند
خیر. پذیرش درخواست با تحویل نهایی متفاوت است. شناسه پیام را ذخیره کنید و نتیجه را از گزارش وضعیت همان سرویس بخوانید.
آیا ارسال الگویی همیشه به شماره مسدودشده می رسد
خیر. امکان ارسال خدماتی به شرایط خط، تأیید الگو و ضوابط ارائه دهنده بستگی دارد. ارسال الگویی تضمین تحویل به همه شماره ها ایجاد نمی کند.
آیا تغییر ارائه دهنده نیازمند بازنویسی کل برنامه است
اگر منطق اعلان از اتصال اختصاصی جدا باشد، می توان تغییرات را بیشتر در لایه ارتباطی متمرکز کرد. بااین حال، تفاوت الگوها، وضعیت ها و روش احراز دسترسی همچنان به تطبیق و آزمایش نیاز دارد.
سلب مسئولیت: ایستگاه آی تی صرفا نمایش‌دهنده این متن تبلیغاتی بوده و سایت مسئولیتی درباره محتوای آن ندارد.
هنوز نظری ثبت نشده
نظرات شما درباره «وب سرویس پیامکی چیست و چگونه...»اولین نفری باشید که نظر میدهید!
نظرات شما میتواند به بهبود محتوا و کمک به دیگران کمک کند.
ثبت اولین نظر