ویکی‌پدیا

انتقال بازنمودی حالت

انتقال بازنمودی حالت (به انگلیسی: Representational state transfer (REST)) یک سبک معماری نرم‌افزاری است که مجموعه ای از محدودیت‌ها را برای استفاده در ایجاد خدمات وب تعریف می‌کند. سرویس‌های وب که مطابق با سبک معماری REST، به نام خدمات وب RESTful هستند، قابلیت همکاری بین سیستم‌های رایانه ای در اینترنت را فراهم می‌کنند. یک وب سرویس RESTful به سیستم‌های متقاضی اجازه می‌دهد تا با استفاده از یک مجموعه یکسان و از پیش تعریف شده از عملیات بدون حالت، به بازنمایی‌های متنی از منابع وب دسترسی پیدا نموده و آنها را دستکاری کنند. انواع دیگر خدمات وب، مانند سرویسهای وب SOAP، مجموعه عملیات دلخواه خود را در معرض نمایش قرار می‌دهند.[۱]

«منابع وب» برای اولین بار در شبکه جهانی وب به عنوان اسناد یا پرونده‌هایی که توسط URLهای آنها مشخص شده بود تعریف شد. با این حال، امروز آنها تعریف بسیار ژرف‌تر و انتزاعی تری دارند که شامل هر چیز یا موجودیتی است که می‌تواند شناسایی، نام گذاری و آدرس دهی شده یا به هر روشی در وب شناسایی شود. در یک وب سرویس RESTful، درخواست‌های ارسال شده به URI منبع، پاسخی را به صورت یک بسته داده در قالب HTML، XML , JSON یا سایر قالب‌ها ایجاد می‌کنند. پاسخ می‌تواند تأیید کند که آیا تغییراتی در منابع ذخیره شده ایجاد شده‌است، و نیز می‌تواند پیوندهای ابر متن به سایر منابع مرتبط یا مجموعه منابع را فراهم کند. هنگامی که از HTTP استفاده می‌شود، به عنوان متداولترین روش، عملیات (متدهای HTTP) موجود عبارتند از: GET , HEAD , POST , PUT , PATCH , DELETE , CONNECT , OPTIONS و Trace.[۲]

با بهره‌وری از یک پروتکل بدون حالت و عملیات استاندارد، سیستم‌های RESTful می‌توانند از کامپاننتهایی که بدون تأثیرگذاری کلی روی سیستم، حتی در حالی که سیستم در حال اجراست، قابلیت مدیریت و بروز شدن دارند، استفاده مجدد نمایند. این ویژگی به این سیستمها اجازه می‌دهد که عملکرد سریع، قابلیت اطمینان و توانایی رشد را داشته باشند.

اصطلاح انتقال بازنمودی حالت در سال ۲۰۰۰ توسط روی فیلدینگ در رساله دکتری وی معرفی و تعریف شد.[۳] پایان‌نامه فیلدینگ، اصول REST را که از آغاز سال ۱۹۹۴ به عنوان "مدل شی HTTP" شناخته می‌شد، توضیح داد و در طراحی استانداردهای HTTP 1.1 و شناسه‌های یکسان منابع (URI) مورد استفاده قرار گرفت.[۴] اصطلاح " انتقال بازنمودی حالت "قصد دارد تصویری از چگونگی رفتار یک برنامه خوش طراحی شده وب ارائه کند: چنین برنامه ای شبکه ای از منابع وب (یک ماشین حالت مجازی) است که کاربر با انتخاب شناسه‌های منبع مانند http://www.example.com/articles/21 و عملیات منبع مانند GET یا POST (انتقال حالت برنامه) می‌تواند در این برنامه پیمایش کند که در نتیجه این عملیات، نمایشی از منابع بعدی آماده شده و برای استفاده به کاربر منتقل می‌شود (تهیه وارائه این نمایش در واقع یک حالت جدید بوده و حالت بعدی برنامه تعیین می‌کند).

تاریخچه ویرایش

 
روی فیلدینگ صحبت کردن در OSCON 2008.

روی فیلدینگ REST را در پایان‌نامه دکترای خود در سال ۲۰۰۰ با عنوان «سبکهای معماری و طراحی معماریهای نرم‌افزاری مبتنی بر شبکه» در دانشگاه ارواین کالیفرنیا تعریف کرد. وی سبک معماری REST را به موازات HTTP 1.1 از ۱۹۹۶–۱۹۹۹، بر اساس طراحی موجود HTTP 1.0[۵] از ۱۹۹۶، توسعه داد.

فیلدینگ در نگاهی گذشته نگر به توسعه REST، گفت:

خصوصیات معماری ویرایش

محدودیت‌های سبک معماری REST بر خصوصیات معماری زیر تأثیر می‌گذارد:[۷]

  • عملکرد در تعامل کامپاننت، که می‌تواند عامل اصلی در عملکرد درک شده توسط کاربر و بهره‌وری شبکه باشد.
  • مقیاس پذیری امکان پشتیبانی از تعداد زیادی از مؤلفه‌ها و تعامل بین مؤلفه‌ها. روی فیلدینگ تأثیر REST در مقیاس پذیری را به شرح زیر توصیف می‌کند:

    مدل کلاینت سرورREST(جداسازی نگرانی‌ها) اجرای مؤلفه را ساده می‌کند، پیچیدگی‌های معنایی متصل کننده‌ها را کاهش می‌دهد، اثر بخشی تنظیم عملکرد را بهبود می‌بخشد و مقیاس پذیری کامپاننتهای خالص سرور را افزایش می‌دهد. محدودیت‌های سیستم لایه ای اجازه می‌دهد تا واسطه‌ها پروکسی، دروازه و فایروال‌ها در نقاط مختلف ارتباطات تعریف شوند بدون اینکه رابط بین کامپاننتها را تغییر دهند، بنابراین به آنها امکان می‌دهند از طریق کش نمودن اشتراکی و در مقیاس بزرگ، در ترجمه ارتباطات یا بهبود عملکرد همراهی کنند. REST پردازش واسط را با محدود کردن پیام‌ها به صورت خود-توصیفی امکان‌پذیر می‌سازد: تعامل بین درخواست‌ها بدون حالت است، از روش‌های استاندارد و انواع رسانه‌ها برای نشان دادن معنایی و تبادل اطلاعات استفاده می‌شود و پاسخ‌ها صریحاً حافظه پنهان را نشان می‌دهند.[۸]

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

محدودیت‌های معماری ویرایش

شش محدودیت راهنما یک سیستم RESTful را تعریف می‌کند.[۷][۹] این محدودیتها روشهای پردازش و پاسخ دادن سرورها به درخواستهای مشتری را محدود می‌کند به گونه ای که با عمل درحیطه این محدودیتها، سیستم از خواص غیر عملیاتی مطلوب مانند عملکرد، مقیاس پذیری، سادگی، اصلاح پذیری، دید، قابلیت حمل و قابلیت اطمینان برخوردار می‌شود. اگر یک سیستم هر یک از محدودیت‌های مورد نیاز را نقض کند، نمی‌توان آن را RESTful در نظر گرفت.

محدودیت‌های رسمی REST به شرح زیر است:

معماری کلاینت سرور ویرایش

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

بی حالت بودن ویرایش

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

قابلیت ذخیره ویرایش

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

سیستم لایه ای ویرایش

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

کد در صورت تقاضا (اختیاری) ویرایش

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

رابط یکسان ویرایش

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

شناسایی منابع در درخواست‌ها
منابع شخصی در درخواست‌ها مشخص می‌شوند، به عنوان مثال استفاده از URI در سرویس‌های وب RESTful. منابع خود به لحاظ مفهومی از بازنمایی‌هایی که به کلاینت برگردانده می‌شوند جدا هستند. به عنوان مثال، سرور می‌تواند داده‌ها را از پایگاه داده خود به صورت HTML، XML یا JSON ارسال کند - که هیچ‌کدام بازنمایش داخلی سرور نیستند.
دستکاری منابع از طریق بازنمایی
هنگامی که کلاینت بازنمایشی از یک منبع را در اختیار دارد، از جمله هر گونه ابرداده پیوست شده، اطلاعات کافی برای تغییر یا حذف منبع دارد.
پیامهای خود- توصیف
هر پیام شامل اطلاعات کافی برای توصیف نحوه پردازش پیام است. به عنوان مثال، کدام توسط یک نوع رسانه می‌تواند مشخص شود که کدام پارسر برای پردازش فراخوانی شود.
ابررسانه به عنوان موتور وضعیت برنامه (HATEOAS)
پس از دستیابی به یک URI اولیه برای برنامه REST- که دقیقامشابه زمانی است که یک کاربر وب حقیقی به صفحه اصلی وب سایت دسترسی پیدا می‌کند - یک کلاینت REST باید بتواند از لینک‌های ارائه شده توسط سرور بطور پویا برای کشف کلیه عملیات و منابع موجود استفاده کند. هر چه دسترسی پیشتر برود، سرور توسط متنی پاسخ می‌دهد که شامل ابرپیوندهایی به سایر حالتهای موجوددر برنامه، می‌باشد. نیازی نیست کلاینت با کدهای سخت برنامه که شامل اطلاعات مربوط به ساختار یا پویایی برنامه می‌شوند، درگیر شود.[۱۲]

کاربرد در وب سرویسها ویرایش

APIوب سرویس های که به محدودیت‌های معماری REST پایبند هستند، APIهای RESTful گفته می‌شوند.[۱۳] APIهای RESTful مبتنی بر HTTP با جنبه‌های زیر تعریف شده‌است:[۱۴]

  • یک URI پایه، مانند http://api.example.com/collection/ ؛
  • روشهای استاندارد HTTP (به عنوان مثال، GET , POST , PUT , PATCH و DELETE).
  • نوع رسانه ای که عناصر داده انتقال وضعیت را مشخص می‌کند (به عنوان مثال، Atom، ریزقالبها، application / vnd.collection + json ,[۱۴] : 91–99  و غیره) بازنمایی فعلی به کلاینت می‌گوید چگونه می‌تواند درخواست‌های انتقال را به حالتهای در دسترس بعدی برنامه مرتبط کند. این می‌تواند به سادگی یک URI یا به پیچیدگی یک اپلت جاوا باشد.[۱۵]

رابطه بین روشهای URI و HTTP ویرایش

جدول زیر نحوه استفاده از روشهای HTTP در API RESTful را نشان می‌دهد.

URI
روشهای HTTP منابع مجموعه مانند https://api.example.com/collection/ منابع عضو، مانند https://api.example.com/collection/item3
GET بازیابی URI از منابع عضو منبع جمع‌آوری در بدنه پاسخ. بازیابی نماینده از منابع عضو در بدنه پاسخ.
POST درست منابع عضو در منابع مجموعه با استفاده از دستورالعمل در بدن درخواست. URI از منبع عضو ایجاد شده به طور خودکار در قسمت هدر پاسخ موقعیت مکانی اختصاص داده می شود. با استفاده از دستورالعمل موجود در بدنه درخواست، یک منبع عضو را در منبع عضو ایجاد کنید. URI از منبع عضو ایجاد شده به طور خودکار در قسمت هدر پاسخ موقعیت مکانی اختصاص داده می شود.
PUT تمام بازنمایی‌های منابع عضو از منابع مجموعه را با بازنمایی در بدنه درخواست جایگزین کنید، یا در صورت عدم وجود منبع جمع‌آوری را ایجاد کنید. به جای تمام بازنمایی‌ها از منابع کاربران و ایجاد منابع عضو اگر وجود ندارد، با نمایندگی در بدنه درخواست.
PATCH به روز رسانی تمام بازنمودهای از منابع، عضو منبع مجموعه با استفاده از دستورالعمل در بدنه درخواست، یا ممکن است منابع مجموعه ایجاد کند وجود ندارد. به روز رسانی تمام بازنمودهای از منابع عضو، یا ممکن است منابع عضو ایجاد کند وجود ندارد، با استفاده از دستورالعمل در بدنه درخواست.
DELETE حذف تمام بازنمایی‌های منابع عضو از منابع مجموعه. حذف همه بازنماییهای منابع عضو.

روش GET بی خطر است، به این معنی که استفاده از آن در یک منبع منجر به تغییر حالت منبع نمی‌شود (فقط خواندنی). [۲] کنید،GET و PUT و DELETE متدهای تکرارشونده هستند، به این معنی که استفاده چندباره از آنها را روی یک منابع، همان تغییرحالت بار اول را در پی خواهد داشت اگر چه پاسخ هر بار می‌تواند متفاوت باشد. [۲]

بحث ویرایش

بر خلاف سرویس‌های وب مبتنی بر SOAP، هیچ استاندارد «رسمی» برای APIهای وب RESTful وجود ندارد. دلیل آن این است که REST یک سبک معماری است، در حالی که SOAP یک پروتکل است. REST به خودی خود استاندارد نیست، اما پیاده‌سازی‌های RESTful از استانداردهایی مانند HTTP، URI , JSON و XML استفاده می‌کند. بسیاری از توسعه دهندگان همچنین APIهای خود را RESTful توصیف می‌کنند، حتی اگر این APIها واقعاً همه محدودیت‌های معماری را که در بالا گفته شد (به خصوص محدودیت رابط یکنواخت) را برآورده نمی‌کنند.[۱۵]

جستارهای وابسته ویرایش

منابع ویرایش

  1. ↑ "Web Services Architecture". World Wide Web Consortium. 11 February 2004. 3.1.3 Relationship to the World Wide Web and REST Architectures. Archived from the original on 29 اكتبر 2017. Retrieved 29 September 2016. {{cite web}}: Check date values in: |archivedate= (help)
  2. ↑ ۲٫۰ ۲٫۱ ۲٫۲ Fielding, Roy (June 2014). "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 4". IETF. Internet Engineering Task Force (IETF). RFC 7231. Retrieved 2018-02-14.
  3. ↑ "Fielding discussing the definition of the REST term". groups.yahoo.com. Retrieved 2017-08-08.
  4. ↑ Fielding, Roy; Gettys, Jim; Mogul, Jeffrey; Frystyk, Henrik; Masinter, Larry; Leach, Paul; Berners-Lee, Tim (June 1999). "Hypertext Transfer Protocol -- HTTP/1.1". IETF. Internet Engineering Task Force (IETF). RFC 2616. Retrieved 2018-02-14.
  5. ↑ "Fielding discusses the development of the REST style". Tech.groups.yahoo.com. Archived from the original on November 11, 2009. Retrieved 2014-09-14.
  6. ↑ خطای یادکرد: خطای یادکرد:برچسب <ref>‎ غیرمجاز؛ متنی برای یادکردهای با نام Fielding-بحث وارد نشده است. (صفحهٔ راهنما را مطالعه کنید.).
  7. ↑ ۷٫۰ ۷٫۱ Erl, Thomas; Carlyle, Benjamin; Pautasso, Cesare; Balasubramanian, Raj (2012). "5.1". SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST. Upper Saddle River, New Jersey: Prentice Hall. ISBN 978-0-13-701251-0.
  8. ↑ خطای یادکرد: خطای یادکرد:برچسب <ref>‎ غیرمجاز؛ متنی برای یادکردهای با نام Fielding-Ch5 وارد نشده است. (صفحهٔ راهنما را مطالعه کنید.).
  9. ↑ Richardson, Leonard; Ruby, Sam (2007). RESTful Web Services. Sebastopol, California: O'Reilly Media. ISBN 978-0-596-52926-0.
  10. ↑ "Fielding talks about application states". Tech.groups.yahoo.com. Retrieved 2013-02-07.
  11. ↑ Lange, Kenneth (2016). The Little Book on REST Services. Copenhagen. p. 19. Archived from the original on 18 August 2019. Retrieved 18 August 2019.
  12. ↑ "REST HATEOAS". RESTfulAPI.net.
  13. ↑ "What is REST API". RESTful API Tutorial. Retrieved 29 September 2016.
  14. ↑ ۱۴٫۰ ۱۴٫۱ Richardson, Leonard; Amundsen, Mike (2013), RESTful Web APIs, O'Reilly Media, ISBN 978-1-4493-5806-8
  15. ↑ ۱۵٫۰ ۱۵٫۱ Roy T. Fielding (2008-10-20). "REST APIs must be hypertext driven". roy.gbiv.com. Retrieved 2016-07-06.

خواندن بیشتر ویرایش

برگرفته از «https://fa.wikipedia.org/w/index.php?title=انتقال_بازنمودی_حالت&oldid=33949874»