source.unsplash.com ختم ہو چکا ہے: پوسٹ مارٹم اور اسے بدلنے کے تمام طریقے

ایک اسٹاک فوٹو سروس نے ایک سب ڈومین بند کر دیا، اور دو سال بعد بھی یہ documentation سائٹس، لاگ ان اسکرینز، کورس کی مشقیں، اور نئے بننے والے کوڈ کو توڑ رہا ہے۔ یہ ایک URL کا پوسٹ مارٹم ہے — یہ کیا کرتا تھا، اسے کیا مار گیا، اور اس کی جگہ کیا رکھا جائے — اور اس کے ساتھ ساتھ اس کہانی کے عجیب تر حصے پر ایک ناپا تلا نظر: وہ مشینیں جو ہمارا کوڈ لکھتی ہیں انہیں یہ نوٹس ہی نہیں ہوا کہ یہ ختم ہو چکا ہے۔

HTTP جوابات، لفظ بہ لفظ نقل کیے گئے دونوں changelog اندراجات، API حدود، ٹوٹنے والے منصوبوں کے issue trackers، اور GitHub، npm اور Stack Overflow سے گنتیاں — سب کچھ بنیادی ذرائع سے آیا ہے، ہر ایک کا طریقہ کار فٹ نوٹس میں دیا گیا ہے۔ اگر آپ صرف حل چاہتے ہیں، تو migration ٹیبل پر جائیں۔

آج آپ کو کیا ملتا ہے، اگر آپ اب بھی درخواست کرتے ہیں

ایک کمانڈ، بغیر کسی کلید کے، کسی بھی مشین سے دوبارہ پیش کیا جا سکتا ہے:

curl -I https://source.unsplash.com/random

HTTP/2 503
cache-control: no-cache, no-store
content-type: text/html; charset=utf-8
server: Heroku
via: 2.0 heroku-router
# باڈی: ایک iframe جو herokucdn.com/error-pages/application-error.html کی طرف اشارہ کرتا ہے

یہاں کچھ بھی DNS ناکامی نہیں ہے۔ source.unsplash.com اب بھی resolve ہوتا ہے — یہ ایک herokudns.com ہوسٹ کا CNAME ہے — اس لیے درخواست کا جواب دیا جاتا ہے، بس کسی ایپلیکیشن کی طرف سے نہیں۔ یہ تفصیل جتنی لگتی ہے اس سے زیادہ اہم ہے: ایک براؤزر جسے ایک تیز 503 HTML باڈی کے ساتھ ملتا ہے وہ ایک ٹوٹی ہوئی تصویر کا placeholder دکھاتا ہے، اور کوئی بھی کوڈ جو response.ok پڑھتا ہو یا کوئی onerror handler جو آپ نے کبھی نہیں لکھا، وہ اسی ناکامی کے راستے پر جاتا ہے جسے آپ نے کبھی ٹیسٹ نہیں کیا۔

ٹیبل کو سائیڈ وے سوائپ کریں تاکہ ہر کالم نظر آئے →

ہر ایک کو الگ سے curl -o /dev/null -w "%{http_code}" کے ذریعے چیک کیا گیا۔ سرچ فیچر پہلے بند کیا گیا، جیسا کہ اعلان کیا گیا تھا؛ آج پوری ایپلیکیشن بند ہے، اس لیے اب یہ فرق موجود نہیں رہا۔

“deprecated” اور “off” کے درمیان تین سال

دونوں اعلانات اب بھی unsplash.com/documentation/changelog پر ایک ہی جگہ پڑھے جا سکتے ہیں۔ مکمل طور پر نقل کیے گئے، کیونکہ الفاظ ہی پوری کہانی ہیں:

25 نومبر 2021 — “Unsplash Source being deprecated”
“Unsplash Source کو deprecate کیا جا رہا ہے۔ موجودہ استعمال کام کرتے رہیں گے، تاہم نئے منصوبوں کے لیے مکمل Unsplash API استعمال کریں۔”

11 جون 2024 — “Unsplash Source sunset”
“Unsplash Source اپنے 2021 کے deprecation کے بعد سے باقاعدہ طور پر unsupported ہے۔ آخری sunsetting کے حصے کے طور پر، ہم پہلے سرچ فیچر کو غیر فعال کر کے اسے بند کریں گے، اور آنے والے ہفتوں میں ایپلیکیشن کو مکمل طور پر بند کر دیں گے۔ Source کے موجودہ استعمال — خاص طور پر production-level استعمال — کو جتنی جلدی ممکن ہو مکمل Unsplash API کی طرف منتقل ہونا چاہیے۔”

انہیں ترتیب سے پڑھیں تو ناکامی کا انداز واضح ہو جاتا ہے۔ 2021 کے نوٹس میں ایک وعدہ تھا (موجودہ استعمال کام کرتے رہیں گے) اور کوئی تاریخ نہیں۔ ایک ڈویلپر جس نے اسے 2021 میں پڑھا، اسے کام کرتے کوڈ کو چھوڑ دینے کی پوری وجہ تھی؛ ایک ڈویلپر جو 2022 میں شامل ہوا، اس نے یہ کبھی پڑھا ہی نہیں۔ 2024 کے نوٹس نے تین سال بعد “آنے والے ہفتے” دیے، ایسے صفحے پر جسے کسی نے bookmark نہیں کیا تھا۔

Unsplash ایک deprecation policy شائع کرتا ہے، اور یہ ایک معقول پالیسی ہے — دستاویزات میں کہا گیا ہے کہ عوامی طور پر دستاویز شدہ فیلڈز اور اینڈ پوائنٹس کے لیے، تبدیلیوں کا اعلان changelog پر کم از کم 3 ہفتے کے نوٹس کے ساتھ کیا جاتا ہے، اور deprecation کے دوران اینڈ پوائنٹس ایک Warning ہیڈر واپس کرتے ہیں۔ اسی پیراگراف میں وہ جملہ بھی ہے جو بتاتا ہے کہ اس میں سے کچھ بھی Source کی حفاظت کیوں نہیں کر سکا: “کسی بھی غیر عوامی طور پر دستاویز شدہ فیلڈز یا اینڈ پوائنٹس کے لیے، ہم بغیر کسی وارننگ کے ان میں تبدیلیاں کر سکتے ہیں۔” Source کبھی دستاویز شدہ API کا اینڈ پوائنٹ نہیں تھا۔ یہ اس پالیسی سے باہر رہا جو اسے احاطہ کرتی۔

• عملی سبق یہ نہیں کہ “Unsplash لاپرواہ تھا”۔ یہ ہے کہ ایک URL جسے آپ بغیر کسی دستاویزات پڑھے استعمال کر سکتے ہیں، وہ ایک ایسا URL بھی ہے جس کی deprecation policy آپ نے بھی نہیں پڑھی۔
• خرابی اعلان سے پہلے شروع ہوئی۔ 28 نومبر 2022 کو دائر ایک Drupal issue پہلے ہی رپورٹ کرتا ہے کہ “مجھے ہمیشہ Heroku application error ملتا ہے”، sunset سے اٹھارہ مہینے پہلے۔ ایسی سروسز اسی طرح مرتی ہیں: آہستہ آہستہ، پھر ایک ایسے اعلان میں جسے آپ کبھی نہیں دیکھتے۔

اعلان outage سے زیادہ ملنا مشکل ہے

2021 کا deprecation changelog.unsplash.com پر شائع کیا گیا تھا، اور یہی وہ URL ہے جس کا حوالہ اس دور کی ہر bug report دیتی ہے — بشمول اوپر دی گئی Drupal کی رپورٹ۔ تین پیمائشیں:

1. HTTPS اینڈ پوائنٹ ٹوٹا ہوا ہے۔ openssl s_client -connect changelog.unsplash.com:443 tlsv1 alert internal error واپس کرتا ہے — کوئی سرٹیفکیٹ پیش کیے جانے سے پہلے ہی handshake ناکام ہو جاتا ہے۔ لہٰذا 2021 کے دور کا ہر لنک، جو https:// تھا، براؤزر میں مردہ ہے۔
2. سادہ HTTP پر یہ redirect کرتا ہے، لیکن کارآمد طریقے سے نہیں۔ http://changelog.unsplash.com/deprecations/2021/11/25/source-deprecation.html کو follow کریں تو دو hops بعد یہ unsplash.com/@documentation/changelog/deprecations/2021/11/25/source-deprecation/html پر 400 پر ختم ہوتا ہے — راستہ سائٹ کے username route میں نگل لیا گیا ہے۔
3. آرکائیو میں وہاں ایک خلا ہے جہاں sunset ہے۔ پرانے changelog کا Wayback Machine کا آخری کامیاب capture 24 مارچ 2024 ہے؛ نئے کا پہلا capture 23 اگست 2024 ہے۔ sunset کا اعلان 11 جون 2024 کو کیا گیا تھا — اسی پانچ مہینے کے خلا کے اندر۔

اس میں سے کچھ بھی سازش نہیں ہے؛ یہ ایک عام CMS migration ہے۔ لیکن نتیجہ حقیقی ہے، اور یہی وہ وجہ ہے کہ یہ مضمون دونوں اندراجات کو مکمل طور پر نقل کرتا ہے: کسی deprecation کا بنیادی ریکارڈ اس چیز سے زیادہ زندہ رہنا چاہیے جسے وہ deprecate کرتا ہے، اور یہاں یہ تقریباً ایسا نہیں ہو سکا۔

اصل میں کیا ٹوٹا

کوئی سائیڈ پروجیکٹس نہیں۔ نیچے دی گئی ناکامیاں عوامی issue-tracker اندراجات ہیں؛ عنوانات، تاریخیں، اور حالتیں GitHub اور drupal.org کے APIs سے آئی ہیں۔

ٹیبل کو سائیڈ وے سوائپ کریں تاکہ ہر کالم نظر آئے →

اس آخری قطار کو دوبارہ پڑھیں، کیونکہ یہی وہ ہے جسے ذہن نشین کرنا ضروری ہے۔ لاگ ان فارم کے پاس ایک سجاوٹی تصویر — صفحے کا سب سے واضح طور پر غیر اہم اثاثہ — ایک تصدیقی outage میں تبدیل ہو گئی، کیونکہ ایک سست third-party درخواست اس CAPTCHA کے سامنے بیٹھی رہی جس کی لاگ ان فارم کو ضرورت تھی۔ کسی نے اسے اس طرح نہیں لکھا۔ یہ اس ترتیب سے سامنے آیا جس میں براؤزر چیزیں لوڈ کرتا ہے۔

آپ کے کوڈنگ اسسٹنٹ کو یہ میمو نہیں ملا

یہاں وہ حصہ ہے جو 2024 کے outage کو 2026 کا مسئلہ بنا دیتا ہے۔ source.unsplash.com تقریباً آٹھ سال تک دستاویز کیا گیا، بلاگ کیا گیا، سکھایا گیا، اور نقل کیا گیا۔ یہ سارا متن ان ماڈلز کے تربیتی ڈیٹا میں ہے جو اب ہمارا اسٹارٹر کوڈ لکھتے ہیں — اور متن کی کوئی میعاد ختم نہیں ہوتی۔ تین گنتیاں:

ٹیبل کو سائیڈ وے سوائپ کریں تاکہ ہر کالم نظر آئے →

سب سے سیدھا ثبوت ایپلیکیشن کوڈ میں بالکل بھی نہیں ہے — یہ پرامپٹس میں ہے۔ اس سرچ کا سب سے اوپر کا نتیجہ GPT سسٹم پرامپٹس کی ایک لائبریری ہے جس میں یہ لائن موجود ہے “please use unsplash API( https://source.unsplash.com/1280x720/?<PUT YOUR QUERY HERE>”۔ وہ ہدایت آج بھی نئے اسسٹنٹس میں نقل کی جا رہی ہے۔ ماڈل URL کی تصدیق نہیں کرتا؛ اسے استعمال کرنے کو کہا گیا تھا، اور جو بھی مثالیں اس نے کبھی دیکھیں، وہ سب اسی پر متفق تھیں۔

لہٰذا generated-code ناکامی کی دو الگ الگ وجوہات ہیں، اور ایک کو ٹھیک کرنے سے دوسری ٹھیک نہیں ہوتی: پرانا تربیتی ڈیٹا، اور اس کے اوپر انسانوں کی لکھی پرانی ہدایات۔ کسی بھی صورت میں، علامت وہی خاندان کی تصاویر ہیں جو کبھی لوڈ نہیں ہوتیں:

source.unsplash.com/random/1200x800   # 2024 کے وسط سے 503 — کبھی واپس نہیں آتا
images.unsplash.com/photo-…           # اصلی CDN، لیکن یاد شدہ IDs موجود نہ ہوں
via.placeholder.com/400               # سرمئی مستطیل، پروڈکشن میں بھیجا گیا
placehold.co/800x600                  # سرمئی مستطیل، جان بوجھ کر
picsum.photos/800/600                 # ایک اصلی تصویر، آپ کے صفحے سے غیر متعلق
/placeholder.png                      # ایک فائل جو کبھی repo میں شامل نہیں کی گئی

اس فہرست کی دوسری لائن پر ایک فٹ نوٹ: یہ لکھتے ہوئے، via.placeholder.com بھی ہمارے ٹیسٹ نیٹ ورک سے TLS handshake مکمل نہیں کر سکا، اور سادہ HTTP پر 403 کے ساتھ جواب دیا۔ اسے اپنے ہی نیٹ ورک سے چیک کریں اس پر بھروسہ کرنے سے پہلے — یہ fallback جس تک یہ ٹولز پہنچتے ہیں، اس کی اپنی outage کہانی ہو سکتی ہے۔

صرف پہلا والا ٹوٹا ہوا ہے۔ باقی زیادہ لطیف طریقے سے بدتر ہیں: وہ لوڈ ہو جاتے ہیں، ترتیب مکمل نظر آتی ہے، اور کسی کو یہ محسوس ہی نہیں ہوتا کہ صفحہ کسی خاص چیز کے بغیر illustrate کیا گیا ہے۔ اور یہ سب کچھ تصاویر تک محدود نہیں — یہ مسئلے کی عمومی شکل ہے۔ ایک ماڈل کی ویب کی تصویر ایک اسنیپ شاٹ ہے، اور اینڈ پوائنٹس، CLI فلیگز، پیکیج کے نام، اور مفت پلانز شٹر بند ہونے کے بعد بھی حرکت کرتے رہتے ہیں۔

Migration ٹیبل

بالکل تین منزلیں ہیں، اور انہیں پیش کرنے کا ایماندارانہ طریقہ یہ ہے کہ آپ کیا چھوڑتے ہیں۔ پہلے کالم چنیں، پھر اپنی قطار پڑھیں۔

ٹیبل کو سائیڈ وے سوائپ کریں تاکہ ہر کالم نظر آئے →

آپشن A وہ ہے جو زیادہ تر لوگ اصل میں چاہتے ہیں۔ اگر تصویر سجاوٹی تھی — ایک ہیرو، ایک لاگ ان سائیڈ پینل، ایک کارڈ بیک گراؤنڈ — تو آپ کو کبھی بھی ہر درخواست پر مختلف تصویر کی ضرورت نہیں تھی۔ ایک چنیں، CDN URL رکھیں، اور صفحہ کسی بھی بے ترتیب چیز پر انحصار کرنا بند کر دیتا ہے:

<img src="https://images.unsplash.com/photo-1506905925346-21bda4d32df4?w=1600&h=900&fit=crop&auto=format"
     width="1600" height="900" alt="…">
# سرکاری طور پر سپورٹڈ پیرامیٹرز: w, h, crop, fit, fm, auto=format, q, dpr۔
# کوئی بھی ixid پیرامیٹر جو API نے دیا، اسے رکھیں — یہی وہ ہے جو view رپورٹ کرتا ہے۔

آپشن B سرکاری راستہ ہے، اور یہ کال کو سرور سائیڈ منتقل کرتا ہے، کیونکہ front-end JavaScript میں ایک Client-ID ایک شائع شدہ credential ہے۔ دو اصولوں پر توجہ دیں جو لوگوں کو الجھاتے ہیں: collections/topics کو ایک ہی درخواست میں query کے ساتھ ملا نہیں سکتے، اور count (زیادہ سے زیادہ 30) جواب کی شکل کو ایک array میں بدل دیتا ہے چاہے وہ 1 ہی کیوں نہ ہو۔

curl "https://api.unsplash.com/photos/random?query=nature&orientation=landscape" \
  -H "Authorization: Client-ID YOUR_ACCESS_KEY" \
  -H "Accept-Version: v1"

# → JSON۔ تصویر .urls.regular / .urls.raw پر ہوتی ہے (w/h/fit خود شامل کریں)۔
# → X-Ratelimit-Limit: 1000   X-Ratelimit-Remaining: 999

آپشن C: Source کو دوبارہ بنائیں، تقریباً چالیس لائنوں میں

اگر آپ نے جو کھویا وہ واقعی رویہ تھا — ایک بغیر کلید کا URL جو ہر بار مختلف تصویر واپس کرتا ہے، جو سیدھا ایک <img> ٹیگ میں، ایک CMS فیلڈ میں، یا ایک static سائٹ میں جہاں کوئی سرور نہیں ہوتا استعمال ہو سکے — تو آپ کو یہ اینڈ پوائنٹ خود چلانا ہو گا۔ یہ API کے سامنے ایک چھوٹا سا worker ہے، اور تین چیزیں جو اسے پروڈکشن میں زندہ رکھتی ہیں وہ ہیں cache، referrer چیک، اور باقی query string کو CDN تک منتقل کرنا۔

// Cloudflare Workers۔ کہیں اور (Deno Deploy, Val Town…) شکل وہی ہے،
// لیکن caches.default کے بجائے caches.open() سے ایک نامزد cache کھولیں۔
// UNSPLASH_KEY سرور سائیڈ ہی رہتا ہے۔ کالرز اسے کبھی نہیں دیکھتے۔
const ALLOWED = ["example.com", "www.example.com"];   // صرف آپ کے ڈومینز
const API_PARAMS = ["query", "collections", "topics", "username", "orientation"];
const TTL = 60;                                       // سیکنڈز — ہر گھنٹے کے quota کی حفاظت کرتا ہے

const host = (value) => { try { return new URL(value).hostname; } catch { return null; } };

export default {
  async fetch(req, env, ctx) {
    // 0. صرف GET: Cache API کسی اور چیز کو محفوظ کرنے سے انکار کرتا ہے، اور ایک امیج
    //    اینڈ پوائنٹ کے پاس جواب دینے کے لیے کوئی اور verb نہیں ہے۔
    if (req.method !== "GET")
      return new Response("Method not allowed", { status: 405 });
    const url = new URL(req.url);

    // 1. صرف آپ کے اپنے صفحات ہی اسے embed کر سکتے ہیں — کھلے انٹرنیٹ پر ایک
    //    عوامی random-photo اینڈ پوائنٹ کسی اور کا rate limit جلا رہا ہے۔
    const ref = req.headers.get("referer");       // بہت سے جائز کلائنٹس میں غائب ہوتا ہے
    if (ref && !ALLOWED.includes(host(ref)))
      return new Response("Forbidden", { status: 403 });

    // 2. ہر پیرامیٹر کے مجموعے کے مطابق cache کریں، تاکہ 12 تصاویر والا صفحہ
    //    ہر منٹ میں بارہ کے بجائے ایک API کال خرچ کرے۔
    const cache = caches.default;
    const hit = await cache.match(req);
    if (hit) return hit;

    // 3. سرکاری API سے ایک بے ترتیب تصویر مانگیں۔
    const api = new URL("https://api.unsplash.com/photos/random");
    for (const p of API_PARAMS)
      if (url.searchParams.has(p)) api.searchParams.set(p, url.searchParams.get(p));

    const r = await fetch(api, { headers: {
      Authorization: "Client-ID " + env.UNSPLASH_KEY,
      "Accept-Version": "v1",
    }});
    // یہاں 403 عام طور پر ہر گھنٹے کا quota ہوتا ہے، کوئی خراب کلید نہیں — TTL بڑھائیں، گھبرائیں نہیں۔
    if (!r.ok) return new Response("Upstream " + r.status, { status: 502 });
    const photo = await r.json();

    // 4. امیج URL دوبارہ بنائیں: ixid رکھیں، کالر کے سائزنگ پیرامیٹرز شامل کریں۔
    const img = new URL(photo.urls.raw);          // .raw میں پہلے ہی ixid ہوتا ہے
    for (const [k, v] of url.searchParams)
      if (!API_PARAMS.includes(k)) img.searchParams.set(k, v);  // w, h, fit, q…

    const res = new Response(null, { status: 302, headers: {
      Location: img.toString(),
      "Cache-Control": "public, max-age=" + TTL,
      // کریڈٹ redirect کے ساتھ سفر کرتا ہے؛ ہیڈر ویلیوز ASCII ہونی چاہئیں، اسی لیے encoding۔
      "X-Photo-Credit": encodeURIComponent(photo.user.name + " on Unsplash"),
      "X-Photo-Link": photo.links.html,
    }});
    ctx.waitUntil(cache.put(req, res.clone()));
    return res;
  },
};

اس کے بعد URL migrate کرنا صرف ایک search-and-replace بن جاتا ہے، جو بالکل وہ چیز ہے جو اس آپشن کو بیس منٹ کے قابل بناتی ہے:

- https://source.unsplash.com/collection/67920491/1600x900
+ https://img.example.com/?collections=67920491&w=1600&h=900&fit=crop

دو ڈیزائن نوٹس، ان دونوں نے لکھے جانے سے پہلے کسی کی ایک بری دوپہر برباد کی۔ bytes کو proxy کرنے کے بجائے redirect (302) استعمال کرنا آپ کو bandwidth سے بچاتا ہے اور view کو Unsplash کے CDN پر شمار رکھتا ہے، جو کہ رہنما ہدایات مانگتی ہیں۔ اور Referer چیک جان بوجھ کر لبرل ہے جب ہیڈر غائب ہو — بہت سے جائز کلائنٹس اسے strip کر دیتے ہیں — جبکہ اب بھی اس واضح صورت حال کو روکتا ہے جہاں آپ کا اینڈ پوائنٹ کسی اور کا مفت امیج API بن جائے۔

وہ اصول جو آپ کو API استعمال کرتے ہی وراثت میں ملتے ہیں

Source کے پاس کوئی اصول نہیں تھے کیونکہ اس کے پاس کوئی اکاؤنٹ نہیں تھا۔ API کے پاس پانچ ایسے اصول ہیں جو اس بات کو بدل دیتے ہیں کہ آپ اسے کیسے آرکیٹیکٹ کرتے ہیں، یہ سب موجودہ دستاویزات سے ہیں:

• Rate limits فی گھنٹہ ہیں، اور شروع میں چھوٹے ہیں۔ demo موڈ میں 50 درخواستیں/گھنٹہ؛ آپ کی ایپلیکیشن پروڈکشن کے لیے منظور ہونے کے بعد 1,000/گھنٹہ۔ صرف api.unsplash.com کو کالز شمار ہوتی ہیں — images.unsplash.com پر امیج درخواستیں شمار نہیں ہوتیں۔ ہر جواب پر X-Ratelimit-Remaining پڑھیں۔
• Hotlinking لازمی ہے، محض اجازت یافتہ نہیں۔ Unsplash کا تقاضا ہے کہ API کے واپس کیے گئے امیج URLs کو براہ راست embed کیا جائے، تاکہ تصویر کے views کا کریڈٹ فوٹوگرافر کو دیا جا سکے۔ فائل کو اپنے CDN پر mirror کرنا وہ ایک اصلاح ہے جو آپ کو کرنے کی آزادی نہیں ہے۔
• ixid پیرامیٹر رکھیں۔ واپس آنے والے URL کا سائز تبدیل کرنا اور کاٹنا متوقع ہے؛ اس پیرامیٹر کو ہٹانا جو آپ کی ایپلیکیشن کی شناخت کرتا ہے، متوقع نہیں ہے۔
• Attribution اور ڈاؤن لوڈ ٹریکنگ اس معاہدے کا حصہ ہیں — فوٹوگرافر اور Unsplash کو کریڈٹ ملتا ہے، اور جب صارف فائل لیتا ہے تو "download" کو تصویر کے download اینڈ پوائنٹ کے ذریعے رپورٹ کیا جاتا ہے، جو ایک ایسا event ہے جو آپ کو خود fire کرنا ہوتا ہے۔
• تقسیم شدہ پروڈکٹس کو dynamic client registration کی ضرورت ہوتی ہے۔ اگر آپ ایک پلگ ان، ایک تھیم، یا خود میزبانی والا CMS بھیجتے ہیں، تو ایک مشترکہ کلید نہ صرف policy کی خلاف ورزی ہے بلکہ ناکامی کا واحد نقطہ بھی ہے؛ API کے پاس اسی صورت حال کے لیے ایک registration flow موجود ہے۔

یہی وہ لمحہ ہے جہاں دائرہ کار کے بارے میں ایماندار ہونا چاہیے: اگر آپ ویسے بھی ایک API اور ایک کلید کو وائر کر رہے ہیں، تو کون سا امیج API استعمال کریں یہ سوال اچانک کھل جاتا ہے، اور اپنا کلائنٹ لکھنے سے پہلے اس پر پانچ منٹ خرچ کرنا فائدہ مند ہے۔ ہم نے مفت والوں کا موازنہ کیا — quotas، اصول، سرچ کا رویہ، اور جواب کی شکل — مفت اسٹاک فوٹو API موازنہ میں۔

اگر آپ کو صرف ایک placeholder چاہیے تھا، تو یہ کہیں

Source کے استعمال کا ایک بڑا حصہ کبھی Unsplash کے بارے میں نہیں تھا۔ یہ “جب میں layout بناؤں تو یہاں کچھ امیج جیسا رکھ دوں” تھا۔ اس کے لیے، بغیر کلید کی سروسز اب بھی موجود ہیں اور صحیح جواب ہیں:

ٹیبل کو سائیڈ وے سوائپ کریں تاکہ ہر کالم نظر آئے →

وہ فرق جو اہم ہے: ایک placeholder تعریف کے مطابق عارضی ہوتا ہے۔ اگر تصویر پروڈکشن تک زندہ رہتی ہے، تو یہ مزید placeholder نہیں ہے — یہ ایک illustration ہے جسے کسی نے نہیں چنا، اور قاری اسے بتا سکتا ہے۔

تین کے بجائے ایک کلید

یہاں migration کا وہ حصہ ہے جس کے لیے کوئی منصوبہ نہیں بناتا: Source چھوڑنے والے لوگ شاذ و نادر ہی ایک API پر پہنچتے ہیں۔ ایک صفحے کو ایک ہیرو، دو سیکشن امیجز، اور کارڈ گرڈ کے لیے کچھ چاہیے ہوتا ہے، اور ایماندارانہ جواب عام طور پر Unsplash plus Pexels plus Pixabay ہوتا ہے — تین رجسٹریشنز، تین auth schemes، تین JSON شکلیں، تین pagination ماڈلز، اور تین attribution rules، یہ سب انہی <img> ٹیگز کو بھرنے کے لیے۔ وہ انٹیگریشن کام ہی اصل بل ہے جو بغیر کلید کے URL کے ختم ہونے پر آتا ہے، اور یہ اس outage کے ہفتوں بعد آتا ہے جس نے اسے شروع کیا۔

اسے ایک انٹیگریشن میں سمیٹنا ہی ہے جس کے لیے ہم نے Pexafy بنایا: ایک ہی سکیما میں 9 مفت-لائسنس لائبریریوں پر ایک واحد کلید، جس کے ساتھ sentence-level سیمنٹک سرچ — تاکہ ایک مکمل تفصیل جیسے “a cracked phone screen on a wooden desk, shot from above” کچھ نہیں کے بجائے درجہ بندی شدہ نتائج واپس کرے۔ دو حدیں، واضح طور پر بیان کی گئیں، کیونکہ یہ پورا مضمون دوبارہ حیران نہ ہونے کے بارے میں ہے: اسے ایک کلید کی ضرورت ہے، اس لیے یہ Source جو تھا اسے واپس بحال نہیں کرتا — یہ اوپر بیان کیے گئے سرکاری Unsplash API کی طرح اسی زمرے میں آتا ہے؛ اور یہ مفت-لائسنس فوٹوگرافی رکھتا ہے، نہ کہ editorial یا برانڈ imagery۔

جو حصہ واقعی نیا ہے وہ اوپر دیے گئے اسسٹنٹس کے لیے ہے: mcp.pexafy.com/mcp پر ایک MCP سرور کا مطلب ہے کہ ایک ماڈل جو ورنہ حافظے سے ایک امیج URL سنا دیتا، وہ ایک اصلی کیٹلاگ سرچ کر سکتا ہے اور ایک ایسی تصویر واپس کر سکتا ہے جو موجود ہے، اس کی کریڈٹ لائن کے ساتھ۔ یہ مشین کے لکھے مردہ URLs کا کسی بھی lint rule سے بہتر جواب ہے، اور اس کی وجوہات AI ایجنٹس کے لیے امیج سرچ انفراسٹرکچر میں لکھی گئی ہیں۔

دس منٹ میں اپنی جائیداد کا آڈٹ کریں

آپ جو بھی migrate کریں، پہلے یہ حصہ کریں — آپ ایسے URLs کو ٹھیک نہیں کر سکتے جو آپ نے تلاش ہی نہیں کیے۔ Source صرف آج کی مثال ہے؛ وہی تین قدمیں ہر بیرونی اثاثے پر لاگو ہوتی ہیں جسے آپ embed کرتے ہیں۔

# 1. repo میں سب کچھ، بشمول docs، tests، fixtures، اور READMEs۔
grep -rn --binary-files=without-match \
  -e "source.unsplash.com" -e "via.placeholder.com" -e "/placeholder.png" .

# 2. ڈیٹابیس میں سب کچھ — CMS باڈیز ہی وہ جگہ ہیں جہاں یہ سب سے زیادہ دیر تک چھپتے ہیں۔
psql -c "SELECT id FROM posts WHERE body LIKE '%source.unsplash.com%'"

# 3. built سائٹ اصل میں جو کچھ درخواست کرتی ہے: اسے crawl کریں اور ناکامیوں کی فہرست بنائیں۔
#    attribute کو میچ کریں، فائل extension کو نہیں — امیج URLs شاذ و نادر ہی .jpg پر ختم ہوتے ہیں۔
grep -rhoE 'src="[^"]+"' dist/ \
  | cut -d'"' -f2 | grep -E '^https?://' | sort -u \
  | xargs -P8 -I{} curl -s -o /dev/null -w "%{http_code} {}\n" {} \
  | grep -v "^200"

# 503 https://source.unsplash.com/random/1200x800   ← وہ جو آپ تلاش کر رہے ہیں

پھر ایک بار طے کریں کہ بیرونی تصاویر آپ کو کتنی قیمت چکانے کی اجازت دیں۔ چار اصول جو اگلے شٹ ڈاؤن سے بچ جاتے ہیں، خواہ اس کا سبب کوئی بھی ہو:

1. build time پر fetch کریں، request time پر نہیں۔ ایک تصویر جو build کے دوران resolve کی جاتی ہے، وہ CI میں، ڈویلپر کے سامنے ناکام ہوتی ہے، صارف کے سامنے صبح 3 بجے نہیں۔
2. کبھی بھی کسی سجاوٹی اثاثے کو ایک اہم راستہ روکنے نہ دیں۔ لاگ ان فارم کے اوپر کوئی بیرونی چیز preload نہ کریں؛ ہر third-party <img> کو ایک onerror fallback اور واضح width/height دیں تاکہ ناکامی کی قیمت ایک خالی باکس ہو، layout shift یا رکی ہوئی script نہیں۔
3. چیک کو CI میں شامل کریں۔ اوپر والا مرحلہ 3، آپ کے built output پر چلایا جائے تو “کسی نے آخر کار محسوس کر لیا” کو ایک سرخ build میں بدل دیتا ہے۔ یہ واحد قدم ہے جو دوبارہ ہونے سے روکتا ہے۔
4. اپنی بیرونی dependencies کو کسی اور کی طرح ہی budget کریں۔ لکھ لیں کہ آپ کے صفحات کن ہوسٹس پر انحصار کرنے کی اجازت رکھتے ہیں اور جب ہر ایک بند ہو تو کیا ہوتا ہے۔ ایک URL جس کے لیے آپ کو رجسٹر کرنے کی ضرورت نہیں پڑی، وہ اب بھی ایک dependency ہے — Source نے ثابت کیا کہ یہ بس ایک ایسی dependency ہے جس کا کوئی مالک نہیں۔

حوالہ جات & فٹ نوٹس