انتقال بازنمودی حالت: تفاوت میان نسخه‌ها

محتوای حذف‌شده محتوای افزوده‌شده

درخط

نسخهٔ ‏۲ آوریل ۲۰۲۰، ساعت ۰۲:۲۵

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

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

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

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

تاریخچه

روی فیلد فیلد REST را در پایان نامه دکترای خود در سال 2000 با عنوان "سبکهای معماری و طراحی معماریهای نرم افزاری مبتنی بر شبکه" در دانشگاه ارواین کلمبیا تعریف کرد . وی سبک معماری REST را به موازات HTTP 1.1 از 1996-1999 ، بر اساس طراحی موجود HTTP 1.0 ^[۵] از 1996 ، توسعه داد.

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

«

در طول فرآیند استاندارد سازی HTTP ، از من خواسته شد تا از گزینه های طراحی وب دفاع کنم. این یک کار بسیار دشوار است که می تواند در طی فرایندی انجام شود که پیشنهادات هر کسی را در مورد موضوعی که به سرعت در حال تبدیل شدن به مرکز کل یک صنعت است ، بپذیرد. من اظهار نظرهایی از بیش از 500 توسعه دهنده داشتم که بسیاری از آنها مهندسین برجسته و با دهه ها تجربه بودند ، و من مجبور بودم همه چیز را از انتزاعی ترین مفاهیم تعامل وب گرفته تا بهترین جزئیات نحو HTTP را توضیح دهم. این فرآیند مدل من را به مجموعه اصلی اصول ، خصوصیات و محدودیت هایی که اکنون 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	به روز رسانی تمام بازنمودهای از منابع، عضو منبع مجموعه با استفاده از دستورالعمل در بدن درخواست، و یا ممکن است منابع مجموعه ایجاد کند وجود ندارد.	به روز رسانی تمام بازنمودهای از منابع عضو، و یا ممکن است منابع عضو ایجاد کند وجود ندارد، با استفاده از دستورالعمل در بدنه درخواست.
حذف	حذف تمام نمایندگی های منابع عضو از منابع مجموعه.	حذف همه نمایه های منابع عضو.

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

بحث

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

همچنین ببینید

اتمی ، قوام ، ایزولاسیون ، دوام (ACID)
URL پاک
ایجاد ، خواندن ، به روزرسانی و حذف (CRUD)
پروتکل درخواست دامنه (DAP)
میکروسرویس ها
مروری بر زبانهای توصیف RESTful API
- مشخصات OpenAPI (سابقا Swagger) - مشخصات تعریف واسط
- OData - پروتکل برای API های REST
- RAML
- RSDL (زبان توصیف سرویس RESTful)
معماری مبتنی بر منابع (ROA)
رایانش مبتنی بر منابع (ROC)
معماری سرویس گرا (SOA)
معماری وب گرا (WOA)

منابع

↑ "Web Services Architecture". World Wide Web Consortium. 11 February 2004. 3.1.3 Relationship to the World Wide Web and REST Architectures. Retrieved 29 September 2016.
↑ ^۲٫۰ ^۲٫۱ ^۲٫۲ 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.
↑ "Fielding discussing the definition of the REST term". groups.yahoo.com. Retrieved 2017-08-08.
↑ 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.
↑ "Fielding discusses the development of the REST style". Tech.groups.yahoo.com. Archived from the original on November 11, 2009. Retrieved 2014-09-14.
↑ خطای یادکرد: خطای یادکرد:برچسب <ref>‎ غیرمجاز؛ متنی برای یادکردهای با نام Fielding-بحث وارد نشده است. (صفحهٔ راهنما را مطالعه کنید.).
↑ ^۷٫۰ ^۷٫۱ 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.
↑ خطای یادکرد: خطای یادکرد:برچسب <ref>‎ غیرمجاز؛ متنی برای یادکردهای با نام Fielding-Ch5 وارد نشده است. (صفحهٔ راهنما را مطالعه کنید.).
↑ Richardson, Leonard; Ruby, Sam (2007). RESTful Web Services. Sebastopol, California: O'Reilly Media. ISBN 978-0-596-52926-0.
↑ "Fielding talks about application states". Tech.groups.yahoo.com. Retrieved 2013-02-07.
↑ Lange, Kenneth (2016). The Little Book on REST Services. Copenhagen. p. 19. Retrieved 18 August 2019.
↑ "REST HATEOAS". RESTfulAPI.net.
↑ "What is REST API". RESTful API Tutorial. Retrieved 29 September 2016.
↑ ^۱۴٫۰ ^۱۴٫۱ Richardson, Leonard; Amundsen, Mike (2013), RESTful Web APIs, O'Reilly Media, ISBN 978-1-449-35806-8
↑ ^۱۵٫۰ ^۱۵٫۱ Roy T. Fielding (2008-10-20). "REST APIs must be hypertext driven". roy.gbiv.com. Retrieved 2016-07-06.

خواندن بیشتر

Pautasso, Cesare; Wilde, Erik; Alarcon, Rosa (2014), REST: Advanced Research Topics and Practical Applications, Springer, ISBN 9781461492986
Pautasso, Cesare; Zimmermann, Olaf; Leymann, Frank (April 2008), "RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision", 17th International World Wide Web Conference (WWW2008)
Ferreira, Otavio (Nov 2009), Semantic Web Services: A RESTful Approach, IADIS, ISBN 978-972-8924-93-5
Fowler, Martin (2010-03-18). "Richardson Maturity Model: steps towards the glory of REST". martinfowler.com. Retrieved 2017-06-26.

[1] "Web Services Architecture". World Wide Web Consortium. 11 February 2004. 3.1.3 Relationship to the World Wide Web and REST Architectures. Retrieved 29 September 2016.

[rfc_7231-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.

[Fielding-discuss-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.

[Fielding-بحث-6] خطای یادکرد: خطای یادکرد:برچسب <ref>‎ غیرمجاز؛ متنی برای یادکردهای با نام Fielding-بحث وارد نشده است. (صفحهٔ راهنما را مطالعه کنید.).

[SOA_with_REST-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.

[Fielding-Ch5-8] خطای یادکرد: خطای یادکرد:برچسب <ref>‎ غیرمجاز؛ متنی برای یادکردهای با نام Fielding-Ch5 وارد نشده است. (صفحهٔ راهنما را مطالعه کنید.).

[Richardson_2007-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. Retrieved 18 August 2019.

[RESTfulAPI.net-12] "REST HATEOAS". RESTfulAPI.net.

[13] "What is REST API". RESTful API Tutorial. Retrieved 29 September 2016.

[Richardson_2013-14] ۱۴٫۰ ^۱۴٫۱ Richardson, Leonard; Amundsen, Mike (2013), RESTful Web APIs, O'Reilly Media, ISBN 978-1-449-35806-8

[must-be-hypertext-driven-15] ۱۵٫۰ ^۱۵٫۱ Roy T. Fielding (2008-10-20). "REST APIs must be hypertext driven". roy.gbiv.com. Retrieved 2016-07-06.

[۱]

[۲]

[۳]

[۴]

[۵]

[۶]

[۷]

[۸]

[۹]

[۱۰]

[۱۱]

[۱۲]

[۱۳]

[۱۴]

[۱۵]