مهندس نرم افزار و کارشناس ارشد مدیریت IT (کسب و کار الکترونیک)
اگه وب سرویس نبودش...
توی مقاله قبلی با عنوان اگه API نبودش پا نمیداد این مقاله با مفهوم API آشنا شدیم و مثالهایی ازش رو دیدیم (لطفاً قبل از ادامه حتماً مطمئن باشید که اون مقاله رو خوندین):
همونطور که اونجا گفته شده، توی این مقاله (اگه وب سرویس نبودش، پا نمیداد این مقاله)، قراره یکم بیشتر وارد مفهوم وبسرویسها بشیم. ولی همچنان، نه خیلی فنی و نه خیلی عمومی، یهچیزِ بِینابِینی که دیدِ قابل قبولی بده و از این به بعد اگه کسی در مورد وبسرویس صحبت کرد یا جایی اسمش رو دیدیم یا شنیدیم، بدونیم چیه و بصورت کلی چه مفهومی داره.
و باز هم (گرچه ویکیپدیا منبع خیلی قابل قبولی برای موارد فنی و علمی نیست ولی برای تعریف و یسری توضیحات خوبه، پس) زحمت تعریف رو میندازیم گردن ویکیپدیای عزیز:
یک وب سرویس (به انگلیسی: Web service) یا خدمت وب، از نگاه فناوری اطلاعات و بر اساس استانداردهای تعریف شده، سرویس یا خدمتی است که از طریق وب (اینترنت) توسط یک دستگاه الکترونیکی (سرور یا خادم) به دستگاه الکترونیکی دیگر (سرویس گیرنده یا Client)، ارائه میشود.
وب سرویس توسط W3C تألیف شده.
عکس زیر API رو با WebService مقایسه کرده
میشه گفت که هر وبسرویس میتونه API باشه، ولی هر API وبسرویس نیست و این موضوع توی همون مقالهای که اول این مطلبق معرفی کردم، مشخص شده.
پس وقتی ما از کلمه ی Web API استفاده میکنیم، احتمالاً منظورمون یه API هست که داره تحت بستر Web خدمات ارائه میده، و وقتی میگیم Web Service، بهتره بدونیم که منظور اصلی، سازوکار ارتباطیای هست برای انتقال اطلاعات بین نرمافزارهای مختلف که گفته میشه توسط سازمان W3C توسعه یافته، و دلیل اصلیش سهولت در انجام امور از راه دور ذکر شده.
ویژگیها
حالا یه سوال، وقتی ما میخوایم کنترل از راه دور انجام بدیم، چه ویژگیهایی لازمه داریم؟
- طبیعتاً یکی از اولین موارد اینه که نحوه ارتباطمون وابستگی خاصی به پلتفرم یا سیستم عامل نداشته باشه
- مورد بعدی اینه که وب سرویس قراره به هرکسی که درخواست میده پاسخی درخور ارائه بده، پس نباید به زبون برنامه نویسی خاصی وابسته باشه
- باید بتونه ارتباط بین بخش های مختلف نرم افزار یا مثلاً ارتباط با کلاینتهای مختلف رو تسهیل کنه
- کسی که از وبسرویس استفاده میکنه نیاز نداره بدونه پشتش چه خبره و فقط باید بدونه چجوری میتونه اطلاعات به وبسرویس بده و ازش اطلاعات دریافت کنه (نیازمند پروتکل ارتباطی هست)
- یه وبسرویس باید ماژولار و داینامیک و و قابل توسعه در ورژنهای مختلف باشه
- اصطلاحاً self-contained باشه، میشه اینجوری تفسیر کرد که حتیالمقدور نیازی به منابع بیرونی نداشته باشه
- در صورت نیاز بتونه تبادل اطلاعات یا اسناد پیچیده رو هم تا حدود قابل قبولی پشتیبانی کنه
فکر کنم کافی باشه تا همینجا ویژگیها.
نقشها
هر جایی، هر جوری، هر کسی، هر طوری، هر نوعی بخواد ارتباط برقرار کنه، نقشها و انتظاراتی مطرح میشه. برای وبسرویسها هم سه نقش کلی و اصلی زیر مطرح میشن:
- ارائهدهنده سرویس یا همون Serviece Provider
همونطور که از اسم مشخصه، منظور شخص یا اشخاص حقیق یا حقوقیای هست که سرویس رو توسعه و ارائه میدن.
- درخواستکننده یا همون Service Requestor
یعنی هر استفادهکننده از وب سرویس که با ارسال درخواست و در صورت نیاز فرستادن دادههایی، پاسخی دریافت میکنه.
- سرویس رجیستری Service Registery
یه واحد مرکزی که توسعهدهندهها میتونن روی اون سرویس جدیدی ایجاد کرده یا از سرویسهای قدیمی که توسط دیگران توسعه داده شده استفاده کنن.
پروتکلها
همونطور که گفتیم وبسرویسها میتونن خدمات و سرویسهایی ارائه بدن، ولی این خدمات با چه استانداردهایی قراره پیادهسازی بشه؟
برخی از انواع پروتکل یا استانداردهای ارتباطی اینا هستن:
- XML یا eXtensible Markup Language:
یکی از استانداردهای اولیه برای استفاده از وبسرویسها، XML هست که این مورد هم توسط W3C استانداردسازی شده تا توسعهدهندگان قادر باشن بصورت استاندارد از این پلتفرم به عنوان واسط اتصال استفاده کنن. زبان XML نوعی زبان نشانهگذاری قابل گسترشه که به منظور انتقال اطلاعات به صورت متن در بین وبسرویسها استفاده میشه.
- SOAP یا Simple Object Access Protocol :
این مورد که شاید توی برخی از ارتباطهای پرداخت و بانکی باهاشون آشنا شده باشین، یکی دیگه از استاندارای مهم و کاربردی در وبسرویسها استاندارد SOAP هست که این پروتکل هم مثل XML میتونه بصورت مشترک باعث اتصال موفق برنامهها با وبسرویس بشه. در واقع پیغامهای ایجاد و ارسال شده SOAP عامل اصلی و ایجاد کننده اتصال وب سرویس هست. این پروتکل برای انتقال اطلاعات با سطح امنیتی بالا مناسبه و تا حدودِ زیادی قابلاطمینان در نظر گفته میشه. بصورت خلاصه میشه گفت SOAP پروتوکلیه برای ارسال داده و اسناد تحت بستر HTTP یا SMTP.
- WSDL یا Web Service Description Language:
یک دیگه از استانداردای مهم که کاربرد بسیار فراوانی توی وبسرویسها داره، استاندارد WSDL هست. این استاندارد هم مثل UDDI یه فایل برای هر وب سرویس داره که این فایل با فرمت XML بوده و بصورت کلی نحوه استفاده از وبسرویس رو شرح میده. به عبارت دیگه، UDDI فهرستی از وبسرویس ها هست که توش نوع و نحوه دسترسی اونا مشخص شده.
- UDDI یا Universal Description – Discovery and Integration :
این استاندارد حاوی یک فایل مبتنی بر XML هست که توسط اون، شرکتها به معرفیِ اتصال وبسرویسها اقدام میکنن. در حقیقت میشه گفت به منظور استانداردسازی انتقال اطلاعات در وبسرویسها ایجاد و توسعه داده میشه. همه رابطهایی که از این استاندارد استفاده میکنن، یه فایل XML دارن که توش رَوشِ بکارگیری، شرح داده شده. این استاندارد روش ارتباط بین وبسرویس و کلاینت رو مشخص میکنه. مایکروسافت یکی از معروفترین شرکت هاییه که به استفاده و توسعه این استاندارد پرداخته. شرکتهای استفادهکننده از این فایل و استاندارد میتونن سطح دسترسی اون رو براحتی حتی جهت معرفی در اختیار شرکتای خاص یا عموم قرار بدن.
معماری
همونطور که فهمیدیم وبسرویسها به روشهای مختلفی میتونن پیادهسازی بشن که هر کدوم مزایا و معایب خودشون رو دارن.
بعضیاشون عبارت هستن از:
- فراخوانی از راه دور - (Remote procedure call)
روش فراخوانی از راه دور (RPC) پروتکلیه که با استفاده از اون یه نرمافزار میتونه یه سرویس رو از نرمافزاری در کامپیوتری دیگه درخواست کنه. به کمک این پروتکل میشه بدون نیاز به دونستن جزئیات شبکه، داخلش به تبادل اطلاعات و برقراری ارتباط بپردازیم.
- سرویس گرا - (Service-oriented architecture)
معماری سرویسگرا (SOA) عملاً یه سبک طراحی نرمافزاره که توش خدمات به کامپوننت های (اجزای نرمافزاریِ) مجزا تقسیم میشن. به این مفهوم که برای جابجایی اطلاعات بین سرویسهای مختلف از این کامپوننتها استفاده میشه.
- رِست - (Representational state transfer - REST API)
میشه گفت معروفترین نوعه که یه سبک معماری برای ایجاد نرمافزارهای تحت شبکه هست که از پروتکلهای مختلف استفاده میکنه. یکی از پرکاربردترین پروتکلها توی این معماری، پروتکل معروف HTTP یا HTTPS هست. این معماری با هدف برقراری ارتباطاتِ نقطهبهنقطه طراحی شده و به راحتی برای محیطای توزیعشده قابل استفاده نیست. یکی از اصلیترین دلایلی که از این نوع استفاده میکنن، سادگی و سهولت پیادهسازی و ارتباطه. وقتی یه سرویس، رِست رو پیاده سازی بکنه، بهش RESTfull گفته میشه. یک از دلایل ایجاد رست هم برطرفکردن مشکلاتی بود با استفاده از پروتوکل SOAP در وبسرویسها بهش برمیخوردن. یه نکته مهم دیگه هم این که رست، میتونه انواع مختلف داده رو پشتیبانی بکنه پس عملاً همه رقمه کار-راه-انداز حساب میشه.
انواع داده
ما وقتی از ارتباط حرف میزنیم، این ارتباط باید به کمک ساختاری که هر دو طرف میتونن بپذیرن و متوجه بشن رخ بده. مثلاً اگه قراره رمزنگاری در کار باشه، یا حتی خیلی سطح پایینتر، اینکه اسناد و دادهها با چه ساختاری برای هر دو طرف قابل درک و تفسیر هستن.
از معروفترین انواع داده که برای ارتباط با وبسرویس در نظر گرفته میشه، میشه به plain text یا رشتههای ساده، html، xml، yaml، toml، json، cson و غیره اشاره کرد که هرکدوم کاربردهای خودشون رو بهتر میتونن داشته باشن و معماریها و پروتکلهای مختلف میتونن یک، بعضی یا همه این موارد رو پوشش بدن.
بیاین مثالهایی برای ارسال داده (اطلاعات یه کتاب) رو ببینیم:
- xml
<book id="bk101">
<author>Gambardella, Matthew</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
<publish_date>2000-10-01</publish_date>
<description>An in-depth look at creating applications
with XML.</description>
</book>
- json
{
"books": [
{
"id": "bk102",
"author": "Crockford, Douglas",
"title": "",
"genre": "Computer",
"price": 29.99,
"publish_date": "2008-05-01",
"description": "Unearthing the Excellence in JavaScript"
}
]
}
- toml
[[books]]
id = 'bk101'
author = 'Crockford, Douglas'
title = ''
genre = 'Computer'
price = 29.99
publish_date = 2008-05-01T00:00:00+00:00
description = 'Unearthing the Excellence in JavaScript'
- cson
books: [
id: 'bk102'
author: 'Crockford, Douglas'
title: ''
genre: 'Computer'
price: 29.99
publish_date: '2008-05-01'
description: 'Unearthing the Excellence in JavaScript'
]
- yaml
books:
- id: bk102
author: Crockford, Douglas
title: ''
genre: Computer
price: 29.99
publish_date: !!str 2008-05-01
description: Unearthing the Excellence in JavaScript
به عنوان یه مثال و برای اینکه بتونیم چیزایی که بالا گفتیم رو کنار هم یه مقایسه داشته باشیم، خوبه که نگاهی به عکس زیر بندازیم (ویژگیهای REST و SOAP)
خب خوشحالم که تا اینجا اومدین. بیان یه جمعبندی بکنیم. ما میخوایم داده، سند، اطلاعات یا موارد قابلِ انتقال رو، بفرستیم یه جایی، و میخوایم ارتباط برقرار کنیم. برای پیادهسازیِ نرمافزاریِ این مقوله، میتونیم این شکلی بگیم که از یه طرف به پروتکل نیاز داریم (که تحت بستر اونها بتونیم اطلاعات منتقل بکنیم)، از طرفی باید ساختار دادهای که میخوایم تحت بستر اون پروتکل ارسال بشه رو انتخاب کنیم، و از طرف دیگه میتونیم وبسرویسی پیاده سازی کنیم که پروتکل و ساختار دادهی مد نظر رو پشتیبانی کنه.
همونطور که اول این مقال گفتم، قرار بود بصورت کلی با ماهیت وبسرویسها آشنا بشیم. برای همین دیگه خیلی وارد جزئیاتشون نشدیم، مثلاً شرح کامل Rest و Soap و نحوه پیادهسازی یه وبسرویس و اجزای مختلفش مثل دیتابیس و ارتباطاتشون و غیره که طبیعتاً در صورت علاقه میتونین در موردشون تحقیق کنید و خیلی هم خوب میشه نتایج رو منتشر کنید تا دیگران هم بتونن استفاده کنن.
امیدوارم این مقاله تونسته باشه دیدِ قابلقبولی در رابطه وبسرویسها بهتون بده.
شاد و سلامت و موفق باشین
توی این مقاله از لینکهایی هم کمک گرفتم، بعضیهاش رو شاید فراموش کرده باشم، ولی میتونید برای آشنایی بیشتر این ده منبع رو هم ببینید (دو تا آخری سرچ مقالات ویرگول هست):
(انگلیسی)
https://www.tutorialspoint.com/webservices
https://www.cleo.com/blog/knowledge-base-web-services
https://rapidapi.com/blog/soap-vs-rest-api
https://www.javatpoint.com/what-is-web-service
https://www.guru99.com/web-service-architecture
(فارسی)
https://7learn.com/programming/what-is-web-service
https://www.faraso.org/blog/...
https://virgool.io/search?q=وب+سرویس
https://virgool.io/search?q=web+service
منتشر شده در ویرگول توسط محمد قدسیان https://virgool.io/@mohammad.ghodsian
https://virgool.io/@mohammad.ghodsian/web-service-gpmxes613ers
مطلبی دیگر از این انتشارات
نکات استقرار برنامه های مبتنی بر NestJS بر روی سرویس ابری لیارا
مطلبی دیگر از این انتشارات
7 باور اشتباه درباره برنامه نویسی که باید فراموش کنید!
مطلبی دیگر از این انتشارات
معرفی و تاریخچه فریمورکSP-Based (مبتنی بر استور پروسیجر)