کثیف شدن دست ها با صابون

بنابراین بله، من به طور اتفاقی با یک مشکل جالب در مورد کثیف شدن دست هایم با صابون مواجه شدم. SOAP پادشاه APIها بود، خوب این قبل از ظهور REST API بود. اگر هنگام تلاش برای اتصال به یک وب سرویس SOAP این مورد را پیدا کردید، بگذارید این یک تشویق برای شما باشد، (در نهایت) از پس آن برمی‌آیید.

پروتکل دسترسی به اشیاء ساده (اگرچه زمانی که با آن شروع می‌کنید خیلی ساده نیست) نحوه تعریف APIها در گذشته است. سرویس‌های SOAP و کلاینت‌ها به زبان جاوا و سی شارپ نوشته شده‌اند و از آنجایی که این زبان‌ها در آن زمان محبوب بودند، پشتیبانی بسیار خوبی در ایجاد مشتری ارائه می‌دهند و به توسعه‌دهنده اجازه می‌دهند تا سرویس را طی کند و در نهایت آنچه را که می‌خواهید بسازد. اما با زبان‌های امروزی مانند NodeJS و Python، این کار هنگام شروع کار کمی دشوار بود.

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

قبل از اتصال واقعی به وب سرویس “مطلوب” زمان آن رسیده بود که با برخی از خدمات وب نمونه که به صورت عمومی در دسترس بودند آشنا شوید.

درک اولیه یک سرویس وب SOAP

اگر با API های REST آشنا هستید، محبوب ترین راه ارتباط با طرحواره از طریق مشخصات OpenAPI (Swagger) است. سرویس‌های وب SOAP از یک WSDL برای برقراری ارتباط با مشخصات سرویس‌ها برای ادغام استفاده می‌کنند.

WSDL

WSDL (زبان تعریف وب سرویس) یک سند XML است که خدمات و عملیات را توصیف می کند (شما می توانید آنها را به عنوان منابع و روش ها در REST در نظر بگیرید). WSDL می‌تواند ارجاعاتی به انواع داده‌ها/طرحواره‌های این عملیات در یک فایل یا فایل‌های مختلف به نام XSD (تعریف طرحواره XML) داشته باشد.

تصویر زیر اصطلاحات SOAP را به REST مرتبط می کند.

برخی از SOAP API در دسترس عموم: https://www.postman.com/cs-demo/workspace/public-soap-apis/request/8854915-c9b8614d-2f25-4eb5-9b39-3715b0d04992

پیام SOAP

سرویس‌های وب SOAP با استفاده از چیزی که پیام SOAP نامیده می‌شود که یک سند XML است ارتباط برقرار می‌کند. مثال زیر را ببینید.

 

 …
 

 
 …
 
 …
 
 

 

SOAP Envelope بیرونی ترین گره است و شامل over all شی درون آن است. گره های فرعی اصلی یک پیام SOAP عبارتند از Header و Body و به صورت اختیاری در صورت بروز خطا، خطا دریافت خواهید کرد. هر پیام SOAP که به سرویس ارسال می کنید باید از این قالب باشد.

فضاهای نام

برای اینکه همه چیز کار کند باید فضاهای نام را درست کنید.

در مثال بالا پیام SOAP “soap:Envelope” که بیرونی ترین عنصر یا گره است که با یک کولون از هم جدا شده است، شامل دو قسمت است.

«صابون»: این فضای نام است. فضاهای نام نقش مهمی دارند. فضاهای نام باید در ویژگی های عنصر XML ارجاع داده شوند. در پیام SOAP فوق xmlns:soap=“http://www.w3.org/2003/05/soap-envelope”، فضای نام “soap” به یک URL ارجاع داده شده است. این به وب سرویس کمک می کند تا عنصر “پاکت” را پیدا/تأیید کند.

یک قانون سرانگشتی این است که اگر فضای نامی به عنصر اضافه شود باید به درستی در ویژگی های XML در همان گره یا گره والد ارجاع داده شود.

هدر و بدنه

من قصد ندارم به طور عمیق در مورد سر و بدن صحبت کنم.

سربرگ (شبیه به هدرها در HTTP؟ بله و خیر، بعداً به آن خواهیم رسید) اما به طور خلاصه، سرصفحه جایی است که شما اعتبارنامه، مهر زمانی، امضا و سایر هدرهای اجباری را خواهید داشت. هدر حاوی اطلاعاتی برای وب سرویس است تا اعتبارسنجی اولیه پیام SOAP شما را انجام دهد.

بدنه جایی است که محموله شما در آن قرار دارد. Payload در قالب XML به گونه ای کدگذاری می شود که سرویس وب آن را درک کند.

احراز هویت

احراز هویت در هر سرویس مهم است، اجازه دهید REST یا SOAP باشد. اما SOAP به دلیل امنیت شناخته شده است. بنابراین لازم است که برای کارکرد آن حق احراز هویت داشته باشید. مشابه API های REST، SOAP با احراز هویت پایه، احراز هویت حامل، گواهینامه های SSL کار می کند.

با این حال، SOAP دارای مشخصات امنیتی تعریف شده WS-Security است که قوانین سخت گیرانه تری را در مورد نحوه احراز هویت تحمیل می کند. یکی از راه های اصلی استفاده از گواهینامه های X.509 برای امضا است. این روشی است که در مورد استفاده ما استفاده شد. این مقاله را به عنوان راهنمای چگونگی امضای قرارداد در نظر نگیرید، فقط یک راهنمای مختصر است. مشخصات اینجا: https://groups.oasis-open.org/higherlogic/ws/public/download/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf/latest

در اینجا یک خلاصه با استفاده از یک الگوریتم خلاصه که در خود خلاصه تعریف می شود، برای عنصر SOAP Body و موارد دیگر مانند برچسب های زمانی به طور جداگانه تولید می شود. هر یک از آنها با استفاده از یک شناسه به خلاصه ارجاع داده می شود.

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

هیچ چیز کار نمی کند

فقط با نگاهی به اسناد موجود در اینترنت، شروع به کدنویسی مشتری برای اتصال به سرویس SOAP با بسته NodeJS NPM کردم. فایل های WSDL را ارائه کرد، یک کلاینت ایجاد کرد، به نام عملیات … “بدون پیکربندی سرویس” و خطای مشتری را می گوید. من هرگز انتظار نداشتم که کد در اولین نمونه کار کند، اما فرض بر این بود که با چند ترفند در تنظیمات کتابخانه کار می کند. فوروارد 4 روز در همان جا گیر کرده بودیم.

جایگزین، گزینه ها

بسته دوم NodeJS https://www.npmjs.com/package/strong-soap وجود داشت که بسیار شبیه به قبلی است، بنابراین من با این کتابخانه امتحان کردم.. هنوز هیچی.

SOAP UI برای نجات

SOAP UI برای شروع بسیار مفید بود. مشتری یک فایل پروژه SOAP UI ارائه کرده بود که ما به راحتی می توانستیم در SOAP UI و voila بارگذاری کنیم … مانند جادو کار می کند. ما توانستیم به سرویس متصل شویم و پاسخ را دریافت کنیم. من توانستم به پیام XML SOAP که کار می کرد نگاه کنم. این بلیط ما برای مهمانی بود.

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

در این زمان من به صابون نگاه کردم و دیدم که از axios برای ارسال پیام SOAP استفاده می کند. من از پیام SOAP کار از SOAP UI استفاده کردم و درخواست را مستقیماً با استفاده از axios ارسال کردم. کار کرد. پس مشکل ما الان با بسته صابون بود.

Debuggers Assemble!

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

بنابراین ما شروع به انجام انواع تغییرات پیکربندی SOAP Client، تغییرات پیکربندی WSDL کردیم. فهرستی از چیزهایی که سعی کردیم پیام SOAP خود را به نمونه کاری نزدیک‌تر کنیم.

1. از overrideRootElement برای یکسان کردن عنصر ریشه استفاده کرد.
2. از ignoredNamespaces برای خلاص شدن از شر فضاهای نام ناخواسته استفاده کرد. (مشکل این بود که از شر فضای نام مورد نیاز به طور کامل در بدنه SOAP خلاص می شد، به زیر مراجعه کنید)
3. فضای نام در بدنه را با استفاده از {‘:name’: ‘value’} به جای فقط {name: ‘value’} لغو کنید، اما هنوز نتوانستیم یکی از فضاهای نام را برای نمایش در ویژگی های XML دریافت کنیم. بنابراین… ما آن را به سختی در شیء JSON {‘:name xmlns=http://namespaces.com/somenamespace’: ‘value’} کدگذاری کردیم.
4. از signerOption برای تنظیم هدر SOAP در WS-Security استفاده کرد.
5. هدرهای گمشده با addSoapHeader اضافه شد (سرصفحه‌های SOAP دارای یک فضای نام “a” (“wsa”) بودند که به آدرس دهی WS اشاره دارد که در پیام SOAP وجود نداشت، ما هدر را به طور کامل از پیام SOAP کار اضافه کردیم)

هنوز وصل نمی شد

مقصر

با تمام تغییرات بالا، ما هنوز یک فضای نام را گم کرده بودیم که http://schemas.xmlsoap.org/ws/2004/08/addressing است. Stackoverflow راه‌های کمی برای اضافه کردن پیشنهاد کرد، اما این (به عنوان روش خصوصی بسته npm توصیه نمی‌شود) روشی است که برای ما کار می‌کند.

client['wsdl']['xmlnsInEnvelope'] += 'xmlns:wsa="http://...."'
client['wsdl']._xmlnsMap();

و.. وویلا
کار کرد.
کلمات پایانی

اگر فکری وجود داشته باشد که بارها و بارها به ذهن من خطور کرده است، “چقدر ممتاز هستیم که امروزه از API های REST استفاده کنیم”. در حالی که API های REST محبوب ترین هستند، سازمان های بزرگتری وجود دارند که هنوز از SOAP API ها به عنوان پیشنهاد خود استفاده می کنند. SOAP به دلیل امنیت شناخته شده است. بنابراین هنوز یک گزینه معتبر برای سازمان هایی است که امنیت را در اولویت قرار می دهند.

به سلامتی، و اینطوری دستم را با صابون کثیف کردم.