23-09-1396، 12:05 ب.ظ
02-10-1396، 09:31 ق.ظ
معماری ReST که مخفف Representational State Transfer هست، از این ایده حمایت میکنه که اپلیکیشن‌های تحت وب باید از HTTP به‌شکلی که در ابتدا پیش‌بینی شده بود استفاده کنن. جستجو در اطلاعات باید از درخواست‌های GET استفاده کنن. درخواست‌های PUT و POST و DELETE هم باید به‌ترتیب برای ویرایش، ایجاد و حذف اطلاعات درنظر گرفته بشن.
معماری ReST از اینکه URLها ساختار مشخصی داشته باشن استقبال میکنه. برای مثال:
اما در اصل این معماری به چنین ساختار Pretty URL احتیاج نداره. یه درخواست GET با پارامتر مثل:
کاملاً یک درخواست معتبر ReSTful محسوب میشه.
به‌خاطر داشته باشین که درخواست‌های GET نباید برای ویرایش اطلاعات بکار برن. برای مثال یه درخواست GET برای اضافه‌کردن آیتمی به سبد خرید مثل:
مناسب نیست. درخواست‌های GET باید درمقابل تکرار بی‌خطر باشن. یعنی اگه یه درخواست رو دوبار صدا بزنیم، نباید تفاوتی با یکبار فراخوانی اون وجود داشته باشه. این‌موضوع باعث میشه که درخواست‌ها قابل کَش‌کردن باشن. درخواست «اضافه‌کردن به سبد خرید» یک درخواست امن دربرابر تکرار نیست (اگه دوبار صداش بزنیم، دو عدد از یک کالا به سبد خرید اضافه میشه). در این وضعیت یک درخواست POST کاملاً مناسبه. بنابراین حتی یک وب‌اپلیکیشن ReSTful هم از درخواست‌های POST سهم خاص خودش رو نیاز داره.
این اطلاعات و جزئیات خیلی بیشتری رو میتونین توی کتاب عالی Core JavaServer faces نوشته‌ی David Geary و Cay Hortsmann پیدا کنید (دانلود).
معماری ReST از اینکه URLها ساختار مشخصی داشته باشن استقبال میکنه. برای مثال:
http://myserver.com/catalog/item/1729
اما در اصل این معماری به چنین ساختار Pretty URL احتیاج نداره. یه درخواست GET با پارامتر مثل:
http://myserver.com/catalog?item=1729
کاملاً یک درخواست معتبر ReSTful محسوب میشه.
به‌خاطر داشته باشین که درخواست‌های GET نباید برای ویرایش اطلاعات بکار برن. برای مثال یه درخواست GET برای اضافه‌کردن آیتمی به سبد خرید مثل:
http://myserver.com/addToCart?cart=314159&item=1729
مناسب نیست. درخواست‌های GET باید درمقابل تکرار بی‌خطر باشن. یعنی اگه یه درخواست رو دوبار صدا بزنیم، نباید تفاوتی با یکبار فراخوانی اون وجود داشته باشه. این‌موضوع باعث میشه که درخواست‌ها قابل کَش‌کردن باشن. درخواست «اضافه‌کردن به سبد خرید» یک درخواست امن دربرابر تکرار نیست (اگه دوبار صداش بزنیم، دو عدد از یک کالا به سبد خرید اضافه میشه). در این وضعیت یک درخواست POST کاملاً مناسبه. بنابراین حتی یک وب‌اپلیکیشن ReSTful هم از درخواست‌های POST سهم خاص خودش رو نیاز داره.
این اطلاعات و جزئیات خیلی بیشتری رو میتونین توی کتاب عالی Core JavaServer faces نوشته‌ی David Geary و Cay Hortsmann پیدا کنید (دانلود).