API एक कॉन्ट्रैक्ट (समझौता) है जिसका इस्तेमाल क्लाइंट किसी सिस्टम से काम करवाने के लिए करता है। इंटरव्यू में, उस कॉन्ट्रैक्ट को यूज़र के मुख्य कामों—जैसे नोट बनाना, उसे पढ़ना, एडिट करना, डिलीट करना और किसी और के साथ शेयर करना—को आसान और अनुमान लगाने लायक बनाना होता है। इसे ऐसी उलझन या अस्पष्टता से भी बचाना होता है जो असुरक्षित हो सकती है; जैसे कि दो अलग-अलग एंडपॉइंट जो नोट को “किसी तरह” अपडेट तो करते हैं, लेकिन एक ही इनपुट पर अलग-अलग तरह से काम करते हैं। आइए, इस कॉन्ट्रैक्ट को सबसे छोटे ‘नोट्स ऐप’ के उदाहरण से समझते हैं, जिसमें मोबाइल या वेब क्लाइंट एक ऐसी बैकएंड सर्विस से बात करता है जो नोट्स को डेटाबेस में स्टोर करती है।
उस बेसलाइन डिज़ाइन में, क्लाइंट API सर्विस को HTTP रिक्वेस्ट भेजता है, API सर्विस उसे वैलिडेट करती है और कॉन्ट्रैक्ट के नियम लागू करती है, और डेटाबेस नोट रिकॉर्ड्स को स्टोर करता है ताकि भविष्य में पढ़ने पर वही स्टेट मिले। मुख्य बात है ‘एजेंसी’ (नियंत्रण)। क्लाइंट चुनता है कि क्या कॉल करना है, API सर्विस तय करती है कि क्या करने की इजाज़त है और क्या लिखा जाएगा, और डेटाबेस रिज़ल्ट को सेव करता है ताकि अगली रिक्वेस्ट उसे देख सके। यह वही स्ट्रक्चर है जिस पर हम बाद में ज़ोर देंगे जब एक सर्वर काफ़ी नहीं रहेगा।
सबसे आसान काम करने वाला API रिसोर्स के नाम साफ़-साफ़ रखता है और हर एंडपॉइंट को एक यूज़र एक्शन और एक स्टोर्ड ऑब्जेक्ट के आकार से जोड़ता है। नोट एक ऐसा ऑब्जेक्ट है जिसमें id, ownerUserId, title, body, और टाइमस्टैम्प होते हैं, और शेयरिंग एक नियम जोड़ती है कि कोई दूसरा यूज़र परमिशन के आधार पर उसे पढ़ या एडिट कर सकता है। इसके साथ, एंडपॉइंट्स का एक छोटा सेट बिना किसी अतिरिक्त वर्ब या बहुत ज़्यादा अर्थ वाले शब्दों के इस्तेमाल के मुख्य फ़्लो को कवर कर सकता है। हर एंडपॉइंट से रीड या राइट पाथ की मैपिंग ही कॉन्ट्रैक्ट को दबाव में भी समझने लायक बनाए रखती है। आइए उन एंडपॉइंट्स को बेसलाइन सर्विस और डेटाबेस रीड और राइट से मैप करें।