חלופה ל-Trakt API

תפקידים שונים, כלים שונים

Trakt מתמקד בנתוני משתמש: היסטוריית צפייה, רשימות מעקב, דירוגים, לוחות שידורים והתחברות עם OAuth. יש לו גם נקודות קצה ציבוריות למטא-נתונים, והמסמכים שלו מציינים את המגבלות החלות. ל-amodb יש תפקיד אחד: מטא-נתונים של סרטים, סדרות ואנשים, שמוחזרים כ-JSON במבנה של TMDB v3. בחרו ב-Trakt למה שהמשתמשים שלכם עשו. בחרו ב-amodb למה שהכותר הוא. רוב האפליקציות שצריכות את שניהם קוראות לכל שירות עבור החלק שלו.

נתוני משתמש מול נתוני כותרים

לקבלת לוחות שידורים, GET /3/tv/airing_today ו-GET /3/tv/on_the_air מציגים סדרות לפי תאריך שידור, ולכל רשומת סדרה יש next_episode_to_air משלה. עבור סדרה שהסתיימה השדה הזה הוא null. שתי הרשימות מתוארות בעמוד טרנדים ורשימות. את לוח השידורים של משתמש אחד מרכיבים מרשומות הצפייה שלכם.

השוואת תכונות

במה amodb שונה

• בלי מסך התחברות למשתמשים שלכם. מפתח בצד השרת מספיק. אף אחד לא מחבר חשבון, ולכן אין אסימון לרענון ואין מסך הסכמה להסביר.
• מגוון שדות רחב. משך, ז'אנרים, חברות הפקה, דירוגי גיל, תרגומים ומילות מפתח מגיעים כולם מנקודות הקצה של הפרטים, בשפה שביקשתם.
• מגבלות מפורסמות. מגבלת המסלול היא מספר לדקה, וכל תגובה מציגה כמה נשאר. מהמספרים האלה אפשר לתכנן סנכרון ברקע.
• מדדי מצב רוח ופסקולים. ההרחבות בעמודים מדדי מצב רוח ופסקולים מוסיפות נתונים שאינם חלק מ-TMDB v3.

מתי Trakt מתאים יותר

• כל מה שאישי. סקרובלינג (scrobbling), סנכרון היסטוריה, רשימות חברתיות ולוחות שידורים לכל משתמש הם יכולות של Trakt. ל-amodb אין חשבונות ואין שיטות כתיבה.
• מצב בין מכשירים. אם משתמש מצפה לראות את אותם סימוני צפייה בטלפון ובטלוויזיה, המצב חייב לחיות בשירות משתמשים, ו-amodb אינו כזה.
• אפליקציות OAuth קיימות. אם האפליקציה שלכם כבר מחזיקה אסימונים של Trakt, המשיכו להשתמש בהם. הוסיפו את amodb רק עבור נתוני הכותרים שאתם מביאים כיום ממקום אחר.

מעבר ל-amodb: חיבור הרשומות שלכם

אין צורך להעביר נתוני משתמש, כי ב-amodb אין כאלה. מחליפים את קריאות המטא-נתונים. פריטי Trakt נושאים מזהים של מאגרים אחרים (את השדות המדויקים ראו במסמכים שלהם), ולכן שמרו את מזהה TMDB או את מזהה IMDb ליד כל רשומת צפייה והשתמשו בו כאן.

<?php
declare(strict_types=1);

function amodb(string $path): array
{
    $ch = curl_init('https://api.amodb.dev/3' . $path);
    curl_setopt_array($ch, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT => 10,
        CURLOPT_HTTPHEADER => ['Authorization: Bearer ' . getenv('AMODB_KEY')],
    ]);
    $body = curl_exec($ch);
    $status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    if ($status !== 200) {
        throw new RuntimeException("amodb returned $status");
    }
    return json_decode($body, true);
}

$show = amodb('/tv/1396?language=en-US');
$next = $show['next_episode_to_air'] ?? null;
echo $show['name'], ' ', $show['status'], PHP_EOL;
echo $next ? 'Next: ' . $next['air_date'] : 'No episode scheduled', PHP_EOL;

כשיש לכם רק מזהה IMDb, קראו פעם אחת ל-/3/find/tt0903747?external_source=imdb_id ושמרו את המזהה מתוך tv_results. תגובת 429 כוללת Retry-After, כמתואר בעמוד מגבלות קצב.

תכנון משימת רענון

ספריית משתמש של 200 סדרות דורשת 200 בקשות פרטים כדי לרענן פעם אחת. ב-20 בקשות לדקה זה לוקח 10 דקות, ב-40 זה לוקח 5, וב-120 זה לוקח פחות מ-2. בדיקת המפתח רצה לפני מטמון הקצה, ולכן גם קריאות חוזרות נספרות. ל-amodb אין פידים של שינויים, ולכן הוא לא יכול לומר אילו מזהים השתנו מאז תאריך מסוים. במקום זאת קראו את status ואת next_episode_to_air מתגובת הפרטים. רעננו לעיתים קרובות סדרות שעדיין משודרות, ורעננו לעיתים רחוקות סדרות שהסתיימו. הפרטים נשמרים במטמון 6 שעות, ולכן רענון תכוף יותר מכך מחזיר את אותם נתונים.

תמחור

amodb הוא בתשלום מראש ואינו מתחדש מעצמו. בחרו 1, 3, 6, 12 או 24 חודשים, שמקנים 0, 10, 20, 30 או 40 אחוז הנחה, ואחד משלושה מסלולים של 20, 40 או 120 בקשות לדקה. כל מסלול מחזיר את כל הנתונים ואין מסלול חינמי. הסכומים מופיעים בעמוד תמחור.