سال‌ها بود که از URI (Uniform Resource Identifier) و URL (Uniform Resource Locator) در پروژه‌های مختلف استفاده می‌کردم، ولی هیچ‌وقت دقیقاً نمی‌دانستم تفاوتشان چیست. برای من، هر دو یعنی آدرسی که در مرورگر تایپ می‌کنم. تا در یک پروژه، همکار تازه‌واردی از من پرسید آیا این مقدار، URI است یا URL — و من نتوانستم جواب درستی بدهم. آن روز فهمیدم که این تفاوت ظاهراً کوچک، در RFC و در طراحی APIها اهمیت جدی دارد. این مقاله پاسخ همان سؤال است، از منظر کسی که سال‌ها این دو را در کد استفاده کرده و حالا تفاوت دقیقشان را می‌داند.

URI یا Uniform Resource Identifier (شناسهٔ یکتای منبع)، یک مفهوم عام است که هر شناسه‌ای برای یک منبع در وب را پوشش می‌دهد. URL یا Uniform Resource Locator (مکان‌یاب یکتای منبع)، زیرمجموعه‌ای از URI است که مکان فیزیکی منبع را نشان می‌دهد. URN یا Uniform Resource Name (نام یکتای منبع)، زیرمجموعه دیگری است که نام پایدار منبع را نشان می‌دهد. اگر تا امروز فکر می‌کردید این سه یکسان هستند، ادامه این مقاله تفاوت‌ها را روشن می‌کند.

URI چیست و چه دامنه‌ای را پوشش می‌دهد؟

URI یا Uniform Resource Identifier، یک استاندارد اینترنتی است که در RFC 3986 تعریف شده و هدفش مشخص کردن یک منبع با یک شناسهٔ یکتا است. این شناسه می‌تواند مکان منبع را نشان دهد، یا فقط نامش را، یا هر دو. مهم‌ترین ویژگی URI این است که هر چیزی که منبعی را در وب شناسایی می‌کند، URI محسوب می‌شود.

URI دو زیرمجموعه اصلی دارد: URL و URN. یعنی هر URL یک URI است، ولی هر URI لزوماً URL نیست. این رابطه، شبیه رابطه بین مربع و مستطیل است: هر مربع یک مستطیل است، ولی هر مستطیل مربع نیست. توضیح این مفاهیم را در API چیست و چه کاربردی دارد؟ هم لمس کرده‌ام، چون در طراحی API این تفکیک اهمیت زیادی دارد.

برای فهم بهتر، دو مثال:

  • https://example.com/posts/123 — این هم URI است، هم URL، چون هم منبع را شناسایی می‌کند و هم مکان فیزیکی آن را نشان می‌دهد.
  • urn:isbn:9780141036144 — این URI است ولی URL نیست، چون منبع را با نام شناسایی می‌کند (شماره ISBN کتاب) ولی مکان فیزیکی آن را نشان نمی‌دهد.

پس URI چتر بزرگی است که هر چیزی که منبعی را شناسایی می‌کند، زیر آن قرار می‌گیرد. تفاوت دقیق URL و URN، همان تفاوت بین مکان و نام است.

URI سؤال می‌پرسد: این منبع چه کسی است؟ URL سؤال می‌پرسد: کجاست؟ URN سؤال می‌پرسد: نامش چیست؟ سه سؤال متفاوت، سه لایه از یک مفهوم.

URL چیست و چه تفاوتی با URI دارد؟

URL یا Uniform Resource Locator، زیرمجموعه‌ای از URI است که مکانی برای دسترسی به منبع را مشخص می‌کند. یعنی URL نه‌فقط منبع را شناسایی می‌کند، بلکه به مرورگر می‌گوید چطور به آن برسد. سه بخش در URL این دسترسی را ممکن می‌کند: پروتکل (Scheme)، دامنه (Host)، و مسیر (Path).

نمونه‌ای دقیق: https://example.com/blog/post-123?utm_source=newsletter#section-2. این URL چهار بخش دارد:

  • https:// — پروتکل دسترسی
  • example.com — دامنه یا هاست
  • /blog/post-123 — مسیر منبع در سرور
  • ?utm_source=newsletter — پارامترهای کوئری
  • #section-2 — قطعه (Fragment) درون صفحه

هر URL دقیقاً همان چیزی است که برای دسترسی به یک منبع در وب لازم دارید. وقتی در مرورگر آدرسی را تایپ می‌کنید، مرورگر URL را می‌فهمد و طبق پروتکل و مسیر، درخواست را می‌فرستد. تفاوت URL با URI این است که URL حتماً شامل اطلاعات مکان است، در حالی که URI می‌تواند فقط نام منبع را داشته باشد.

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

URN چیست و چه زمانی به‌کار می‌آید؟

URN یا Uniform Resource Name، زیرمجموعه دیگری از URI است که منبع را با یک نام پایدار و مستقل از مکان شناسایی می‌کند. تفاوت اصلی URN با URL این است که URN هیچ اطلاعاتی درباره مکان منبع نمی‌دهد. یعنی اگر منبع جابه‌جا شود، URN عوض نمی‌شود.

نمونه‌ای کلاسیک: urn:isbn:9780141036144. این URN یک کتاب را با شماره ISBN (شماره استاندارد بین‌المللی کتاب) شناسایی می‌کند. مهم نیست این کتاب در کدام فروشگاه یا کتابخانه است؛ URN همین می‌ماند. همین ویژگی URN را برای سیستم‌هایی که پایداری شناسه در آن‌ها حیاتی است، مناسب می‌کند.

در عمل، URN در وب امروز کمتر از URL استفاده می‌شود، چون وب‌سایت‌ها معمولاً به مکان فیزیکی منبع نیاز دارند. اما در برخی سیستم‌های توزیع‌شده، در کتابخانه‌های دیجیتال و در توصیف منابع، URN بسیار مفید است. مکانیزم DOI (Digital Object Identifier) برای مقالات علمی، یک نمونه از همین کاربرد است که در ادامه به آن می‌رسم.

یک نکتهٔ ظریف: تفاوت URN با URL در این نیست که کدام بهتر است. هرکدام برای سناریوی خاصی طراحی شده‌اند. URL برای دسترسی فوری، URN برای شناسایی پایدار.

ساختار URI: هر بخش چه معنایی دارد؟

ساختار URI در RFC 3986 به‌طور رسمی تعریف شده و شامل پنج بخش است:

بخشمثالکارکرد
Schemehttps://پروتکل دسترسی
Authorityuser@example.com:443اطلاعات احراز هویت و هاست
Path/blog/post-123مسیر منبع
Query?id=123پارامترهای پویا
Fragment#section-2اشاره به بخشی از منبع

در URL، بخش Authority معمولاً شامل هاست و پورت است و اطلاعات احراز هویت (user:password) خیلی کم استفاده می‌شود. در URIهای غیر URL (مثل URN)، ساختار می‌تواند ساده‌تر یا کاملاً متفاوت باشد. مثال urn:isbn:9780141036144 فقط Scheme (urn) و یک شناسه دارد، نه Authority و نه Path.

نکته‌ای که در پروژه‌های API زیاد به کارم می‌آید: در طراحی endpointها، هر بخش URI یک کارکرد دارد و نباید قاطی شود. مثلاً استفاده از Query برای فیلتر گذراست ولی برای شناسایی منبع درست نیست. راهنمای کامل این اصول در کاربرد URI در طراحی API آمده است.

تفاوت URI، URL و URN در یک نگاه

برای جمع‌بندی، تفاوت‌ها را در جدول کنار هم می‌گذارم:

معیارURIURLURN
تعریفهر شناسه منبعشناسه با مکانشناسه با نام پایدار
رابطهمفهوم عامزیرمجموعه URIزیرمجموعه URI
شامل مکان؟ممکن استبله، همیشهخیر، هرگز
مثالhttps://example.com یا urn:isbn:...https://example.comurn:isbn:9780141036144
کاربرد اصلیهرجا که منابع را شناسایی کنیممرورگر و APIهاسیستم‌های شناسایی پایدار

یک قاعده ساده که همیشه به کارم می‌آید: اگر یک مقدار، پروتکل و دامنه دارد (یا حداقل یکی از آن‌ها)، احتمالاً URL است. اگر پروتکل دارد ولی دامنه و مسیر ندارد و فقط یک شناسه یکتاست، URN است. اگر مطمئن نیستید، از واژه URI استفاده کنید، چون همیشه درست است.

کاربرد عملی: کجا از URI و کجا از URL استفاده می‌کنیم؟

در عمل، تفاوت URI و URL بیشتر در ادبیات فنی و استانداردها خودش را نشان می‌دهد. اما در چند جای مشخص، استفاده نادرست از اصطلاح، مشکل‌ساز می‌شود:

مرورگر و درخواست‌های HTTP

در مستندات HTTP و در ساختار درخواست HTTP، اصطلاح درست URI است. مثلاً هدرهای HTTP مثل Host و Referer بر مبنای URI تعریف شده‌اند. اگر در مستندات فنی بنویسید URL، اشتباه نیست ولی رایج نیست.

سیستم‌های شناسایی منابع

در سیستم‌هایی که به شناسایی پایدار منابع نیاز دارند (مثل کتابخانه‌ها، سیستم‌های DOI و کاتالوگ‌های موزه)، URN و URI استفاده می‌شود. مثال DOI به شکل doi:10.1000/182 خود یک URI است که در ابتدایش doi: به‌عنوان Scheme دارد.

مراجع Web و XML

در XML و در تعریف Namespace، هر جا که به یک منبع ارجاع داده می‌شود، اصطلاح URI استفاده می‌شود. همین در طراحی معماری‌های مبتنی بر XML، رایج است.

طراحی API و مستندات

در مستندات OpenAPI و در APIهای REST، معمولاً اصطلاح URI رایج است، به‌خصوص در تعریف endpointها. اشاره‌های دقیق‌تر در اصول طراحی REST API آمده است.

محتوای روزمره و وبلاگ

در محتوای عمومی و مقالات وب، معمولاً اصطلاح URL رایج‌تر است چون برای کاربر نهایی قابل‌فهم‌تر است. مهم نیست URL دقیقاً URI هم هست یا نه؛ کاربر می‌خواهد بداند آدرس سایتی که در مرورگر تایپ می‌کند کجاست.

URI در طراحی API و REST

در طراحی APIهای REST (Representational State Transfer)، URI نقش کلیدی دارد. هر منبع در API یک URI منحصربه‌فرد دارد و عملیات با متدهای HTTP روی آن انجام می‌شود. مثلاً:

GET /api/users/123
POST /api/users
PUT /api/users/123
DELETE /api/users/123

هر یک از این URIها به یک منبع مشخص اشاره می‌کنند و متد، عملیات را تعیین می‌کند. قاعده‌های دقیق این طراحی در اصول طراحی REST API و REST API چیست؟ آمده است.

نکته‌ای که در بازبینی APIها زیاد می‌بینم: بعضی توسعه‌دهندگان از URI برای انتقال داده استفاده می‌کنند، مثلاً /get-user?id=123 به‌جای /users/123. این طراحی با فلسفه URI در تعارض است، چون URI باید منبع را توصیف کند نه عمل را. تفاوت URI و URL در اینجا مهم می‌شود: URI یک شناسه است، نه یک دستور.

رابطه URI با نسخه‌بندی API هم مهم است. مثلاً /api/v2/users/123 هم URI است و هم URL، ولی بخش v2 یک شناسه نسخه است که بخشی از URI محسوب می‌شود. راهنمای کامل نسخه‌بندی در نسخه‌بندی REST API آمده است.

URI در مرورگر و واقعیت وب

در دنیای واقعی وب، تفاوت URI و URL کمتر محسوس است. وقتی کاربری آدرسی را در مرورگر تایپ می‌کند، مرورگر آن را به‌عنوان URL می‌فهمد. اما اگر همان آدرس را در XML بگذارید یا در طراحی API استفاده کنید، استاندارد آن را URI می‌نامد.

حتی در مستندات گوگل و در استانداردهای وب، گاهی این دو اصطلاح به‌جای هم استفاده می‌شوند. این تنوع، ریشه تاریخی دارد: قبل از RFC 3986، این تفکیک دقیقاً یکسان تعریف نشده بود و در عمل، همین ابهام باقی ماند. RFC 3986 دقیقاً برای شفاف‌سازی این تفکیک منتشر شد و در آن، URI به‌عنوان سقف تعریف شد و URL و URN زیرمجموعه‌هایش.

برای توسعه‌دهنده وب، مهم است این تفکیک را در ذهن داشته باشد ولی در مستندات روزمره، استفاده از هرکدام که رایج‌تر است، اشکالی ندارد. تنها جایی که اهمیت واقعی دارد، در طراحی APIهای عمومی و مستندات فنی است.

اشتباهات رایج در استفاده از این اصطلاحات

در بازبینی مستندات و کد پروژه‌ها، چند اشتباه را زیاد دیده‌ام:

  • فرض این‌که URI و URL یکسانند: از نظر فنی غلط است. URI مفهوم عام است و URL زیرمجموعه‌اش. در مستندات فنی، این تفکیک را رعایت کنید.
  • استفاده از URN برای منابعی که مکان دارند: اگر منبع در وب قابل دسترسی است، URN مناسب نیست. URN فقط برای شناسایی پایدار، بدون اشاره به مکان.
  • نادیده گرفتن بخش Fragment در URI: بخش #section-2 هرگز به سرور ارسال نمی‌شود و فقط در مرورگر پردازش می‌شود. این نکته در طراحی صفحه‌های تک‌صفحه‌ای مهم است.
  • مشکل با کاراکترهای خاص: URI فقط از کاراکترهای ASCII پشتیبانی می‌کند و برای کاراکترهای یونیکد باید Encode شود. مثلاً در URL فارسی، از percent-encoding استفاده می‌شود. تفاوت URL انگلیسی و فارسی در تفاوت قالب فارسی و انگلیسی با نگاه به ساختار URL بررسی شده است.
  • استفاده از اصطلاح نادرست در مستندات: در مستندات OpenAPI، بهتر است از واژه URI استفاده کنید. در وبلاگ عمومی، واژه URL برای مخاطب غیرفنی قابل‌فهم‌تر است.

پاسخ به پرسش‌های پرتکرار درباره URI، URL و URN

URI چیست به زبان ساده؟

URI یا Uniform Resource Identifier، هر شناسه‌ای است که یک منبع را در وب مشخص می‌کند. URI چتر بزرگی است که هر آدرس، شناسه یا نام یکتای منبع را پوشش می‌دهد. URL و URN دو زیرمجموعه URI هستند. اگر مطمئن نیستید یک مقدار URI است یا URL، آن را URI بنامید چون همیشه درست است.

تفاوت اصلی URI و URL در چیست؟

تفاوت اصلی این است که URL زیرمجموعه URI است و حتماً مکان منبع را نشان می‌دهد. URI مفهوم عام است و ممکن است فقط نام منبع را داشته باشد (در آن حالت URN می‌شود). مثلاً https://example.com هم URI است و هم URL، ولی urn:isbn:9780141036144 فقط URI است و URN محسوب می‌شود.

آیا URN در وب امروز کاربرد دارد؟

بله، هرچند کمتر از URL. URN در سیستم‌های شناسایی پایدار مثل DOI برای مقالات علمی، ISBN برای کتاب‌ها، و کاتالوگ‌های کتابخانه‌ای استفاده می‌شود. کاربرد اصلی URN جایی است که پایداری شناسه مهم‌تر از مکان فیزیکی است.

چرا در مستندات HTTP از اصطلاح URI استفاده می‌شود؟

چون استاندارد HTTP (RFC 7230 و نسخه‌های جدیدتر) بر مبنای RFC 3986 تعریف شده که اصطلاح URI را به‌عنوان مفهوم عام استفاده می‌کند. در مستندات فنی HTTP، این دقت لازم است چون ممکن است منبعی با پروتکل‌های غیر HTTP هم قابل دسترسی باشد.

آیا در وردپرس تفاوت URI و URL اهمیت دارد؟

در بیشتر موارد کاربردی، تفاوت URI و URL در وردپرس محسوس نیست. وردپرس با URL کار می‌کند و ساختار پیوندهای یکتا (Permalinks) بر مبنای URL است. اما اگر افزونه یا سرویسی بسازید که با استانداردهای REST یا XML کار می‌کند، رعایت اصطلاح URI دقت مستندات را بالا می‌برد. راهنمای ساختار URL در وردپرس در ساختار URL حرفه‌ای و سئو آمده است.

آیا برای سئو تفاوت URI و URL اهمیت دارد؟

خیر، برای سئو تفاوت عملی وجود ندارد. گوگل با URL کار می‌کند و ساختار پیوندهای یکتا بر سئو اثر مستقیم دارد. توصیه گوگل در مستندات Search Central این است که URLها خوانا، کوتاه و معنادار باشند. تفاوت مفهومی URI و URL در اینجا بی‌اثر است.

چگونه در مستندات فنی، اصطلاح درست را انتخاب کنیم؟

یک قاعدهٔ ساده: اگر مستندات برای توسعه‌دهندگان است یا از استانداردهای وب صحبت می‌کند، از واژه URI استفاده کنید. اگر برای کاربران نهایی یا محتوای عمومی است، واژه URL قابل‌فهم‌تر است. در مستندات OpenAPI، واژه URI رایج است؛ در وبلاگ‌های سئو، واژه URL رایج است.

خط پایان: یک نقشه ذهنی برای همیشه

URI، URL و URN سه مفهومند که سال‌ها با هم اشتباه گرفته می‌شوند، ولی تفاوتشان ساده است. URI سقف است؛ URL زیرمجموعه‌ای که مکان را نشان می‌دهد؛ URN زیرمجموعه‌ای که فقط نام را نشان می‌دهد. در کار روزمره وب، بیشتر با URL کار می‌کنیم؛ در مستندات فنی و طراحی API، URI دقیق‌تر است. اگر این نقشه ذهنی را یک بار درست در ذهن داشته باشید، در هر جایی می‌دانید کدام اصطلاح درست است.

پیشنهاد عملی من سه گام است. اول، در مستندات فنی پروژه‌های خودتان، یک‌بار همه موارد «URL» را بازبینی کنید و ببینید کجا باید «URI» باشد. دوم، در طراحی APIهای بعدی، از ابتدا URI را به‌عنوان مفهوم عام در نظر بگیرید. سوم، در محتوای عمومی و وبلاگ، همان URL را استفاده کنید که مخاطب می‌فهمد.

اگر تجربه‌ای از اشتباه یا ابهام در این مفاهیم در پروژه‌های خودتان دارید — به‌خصوص اگر در مستندات فنی یا طراحی API با این تفکیک درگیر شده‌اید — برایم بنویسید. همین تجربه‌های میدانی، به خواننده بعدی کمک می‌کند نقشه ذهنی دقیق‌تری بسازد. 🔗