Lecture 01 · Introduction
المحاضرة 01 · مقدمة
Relationships: protocol plus interface, safe and idempotent
العلاقات: البروتوكول زائد الواجهة، والآمن (safe) والمتساوي الأثر (idempotent)
P1 MUSTP1 ضروريDesign questions 3 and 4 for the lamp. What connects client and server (a protocol plus an interface), the two interactions written as request and reply, the one calculation in this block, and the difference between the server component and the server layer.
سؤالا التصميم 3 و4 للمصباح. ما الذي يربط client بـ server (protocol زائد interface)، والتفاعلان مكتوبين على شكل طلب ورد، والحساب الوحيد في هذا الجزء، والفرق بين server component وserver layer.
This block is dense with one-line definitions that make perfect true/false and matching items: relationship = protocol + interface, safe versus idempotent, server component versus server layer. It also holds the only arithmetic in the introduction (energy in kWh), and the slide itself gets the unit wrong. Work every item below with a pen.
هذا الجزء مليء بتعريفات من سطر واحد تصلح تماماً لأسئلة صح أو خطأ والتوصيل: relationship = protocol + interface، وsafe مقابل idempotent، وserver component مقابل server layer. وفيه أيضاً الحساب الوحيد في المقدمة (الطاقة بـ kWh)، والشريحة نفسها تخطئ في الوحدة. حلّ كل بند أدناه بالقلم.
Question 3: what is a relationship?
السؤال 3: ما هي العلاقة (relationship)؟
Slide 16 starts with a single arrow labelled Relationship between Client and Server, then redraws it as three separate arrows labelled 1, 2, 3: Interactions. The bullets:
تبدأ الشريحة 16 بسهم واحد مسمّى Relationship بين Client وServer، ثم تعيد رسمه ثلاثة أسهم منفصلة مرقّمة 1 و2 و3 باسم Interactions. ونقاطها:
- A relationship between two components captures the interactions between the components.
الـ relationship بين مكوّنين تلتقط التفاعلات (interactions) بينهما.
- A relationship can involve multiple interactions. An interaction d is an element of a relationship R.
قد تتضمن الـ relationship تفاعلات متعددة. والتفاعل d عنصر من عناصر العلاقة R.
- A relationship is defined using a protocol and an interface.
الـ relationship تُعرَّف باستخدام protocol وinterface.
d ∈ R: التفاعل عنصر واحد من مجموعة العلاقة. وRelationship = Protocol + Interface. الـ protocol مثل HTTP، والـ interface هي endpoints أو methods التي يستطيع client استدعاءها.
Protocol: how do we talk?
البروتوكول (Protocol): كيف نتحدث؟
The grammar both sides agree on: message format, order and meaning. For the Web that is HTTP, with its methods, headers and status codes.
القواعد التي يتفق عليها الطرفان: شكل الرسالة وترتيبها ومعناها. وفي الويب هو HTTP بما فيه من methods وheaders وstatus codes.
Interface: what can I ask for?
الواجهة (Interface): ماذا يمكنني أن أطلب؟
The list of operations the server offers. On the Web each one is an endpoint: a method plus a path, such as GET /lamp/energy. Together they form the Web API.
قائمة العمليات التي يقدّمها الـ server. وفي الويب كل واحدة منها endpoint: method زائد مسار، مثل GET /lamp/energy. ومجموعها هو الـ Web API.
The boxed sentence on slide 16 is the one to quote: in a web app, the client (browser) interacts with the server via HTTP requests (protocol) to access APIs (interface). Neither half is enough alone. A shared language with nothing to ask for is useless, and a menu of operations nobody can phrase is equally useless.
الجملة المؤطّرة في الشريحة 16 هي التي تُقتبس: في تطبيق الويب يتفاعل الـ client (المتصفح) مع الـ server عبر طلبات HTTP (الـ protocol) للوصول إلى APIs (الـ interface). ولا يكفي نصف واحد وحده. لغة مشتركة بلا شيء تطلبه عديمة الفائدة، وقائمة عمليات لا يستطيع أحد صياغة طلبها عديمة الفائدة كذلك.
The relationship we deliberately ignore
العلاقة التي نتجاهلها عمداً
Slide 17 asks about the other arrow, server to device, and answers bluntly: it is not of concern to us. You can assume the server runs on a microcontroller board that interfaces with the device, and the server uses a library to interact with it (the photo shows a board, a relay and a bulb).
تسأل الشريحة 17 عن السهم الآخر، من server إلى device، وتجيب بصراحة: ليس من شأننا. يمكنك أن تفترض أن الـ server يعمل على لوحة microcontroller متصلة بالجهاز، وأن الـ server يستخدم مكتبة (library) للتعامل معه (والصورة تُظهر لوحة وrelay ومصباحاً).
That is a design decision, not laziness. The program calls a library, the library switches a pin, the pin drives a relay, the relay switches the lamp: a separate lower-level relationship with its own protocol and interface. The web client never sees it. Two consequences worth a mark: the server need not sit in a data center (here it sits next to the lamp), and swapping the relay for a smart bulb does not change the client at all.
هذا قرار تصميمي وليس كسلاً. البرنامج يستدعي مكتبة، والمكتبة تبدّل pin، والـ pin يشغّل relay، والـ relay يشغّل المصباح: علاقة منفصلة في مستوى أدنى لها protocol وinterface خاصان بها. والـ client لا يرى منها شيئاً. ونتيجتان تستحقان درجة: الـ server لا يلزم أن يكون في data center (هنا هو بجانب المصباح)، واستبدال الـ relay بمصباح ذكي لا يغيّر الـ client إطلاقاً.
The two lamp interactions
تفاعلا المصباح
Slide 18 writes the relationship's set down. Two interactions, each a request from the client and a reply from the server. The client always speaks first, and the device sits behind the server, never talking to the client directly.
تكتب الشريحة 18 مجموعة العلاقة صراحة: تفاعلان، كل منهما طلب من client ورد من server. الـ client يبدأ دائماً، والـ device يقع خلف الـ server ولا يتحدث مع الـ client مباشرة أبداً.
| Interaction (slide 18)التفاعل (الشريحة 18) | Request carriesما يحمله الطلب | Replyالرد | HTTP (slide 19)HTTP (الشريحة 19) |
|---|---|---|---|
| Set_on_off | The target state, on or offالحالة المطلوبة، تشغيل أو إطفاء | ok | PUT /lamp/state |
| read_energy_usage | Nothing extraلا شيء إضافي | An energy value in kilowatt-hoursقيمة طاقة بوحدة الكيلوواط ساعة (kWh) | GET /lamp/energy |
One design detail matters more than it looks. Set_on_off should carry the value you want, not mean "toggle". If the reply is lost and the client sends the request again, a toggle flips the lamp back off, while "set on" twice still leaves it on. Hold that thought: it is the property called idempotent, two sections down.
تفصيل تصميمي واحد أهم مما يبدو. يجب أن يحمل Set_on_off القيمة التي تريدها، لا أن يعني "اقلب الحالة" (toggle). إن ضاع الرد وأعاد الـ client إرسال الطلب، فإن الـ toggle يعيد المصباح إلى الإطفاء، بينما "شغّل" مرتين تُبقيه مشتعلاً. احتفظ بهذه الفكرة: هي الخاصية المسمّاة idempotent بعد قسمين.
The one calculation: energy, not power
الحساب الوحيد: الطاقة وليس القدرة
The reply to read_energy_usage is energy, and that is where students slip. A watt measures power, a rate: how fast energy is used. A watt-hour measures energy: that power kept up for some time. A kilowatt-hour is 1 kW (1,000 W) for one hour.
الرد على read_energy_usage طاقة، وهنا يتعثّر الطلاب. الـ watt يقيس القدرة (power)، وهي معدّل: سرعة استهلاك الطاقة. والـ watt-hour يقيس الطاقة (energy): تلك القدرة مستمرة مدة من الزمن. والـ kilowatt-hour هو 1 kW (1,000 W) لمدة ساعة واحدة.
E = P × t، أي الطاقة تساوي القدرة مضروبة في الزمن، وkWh = (watts × hours) ÷ 1000.
Power P = 100 W. Time t = 10 h.
P = 100 W للقدرة، وt = 10 h للزمن.
Multiply: 100 W × 10 h = 1,000 Wh.
نضرب: 100 W × 10 h = 1,000 Wh.
Convert: 1,000 Wh ÷ 1000 = 1 kWh. That is what read_energy_usage returns.
نحوّل: 1,000 Wh ÷ 1000 = 1 kWh. وهذه هي القيمة التي يعيدها read_energy_usage.
The slide's error: its footnote writes "100 watts x 10 = 1,000 watts (or 1 kilowatt hour)". The parenthesis is right, the "1,000 watts" is wrong: 1,000 W is a power (1 kW), not an amount of energy, and the 10 lost its unit (hours). Write 1,000 Wh = 1 kWh.
خطأ الشريحة: الحاشية تكتب "100 watts x 10 = 1,000 watts (or 1 kilowatt hour)". ما بين القوسين صحيح، أما "1,000 watts" فخاطئ: 1,000 W قدرة (1 kW) لا كمية طاقة، والـ 10 فقدت وحدتها (ساعات). اكتب 1,000 Wh = 1 kWh.
Two more to practise: 60 W for 5 h = 300 Wh = 0.3 kWh. A 2 kW heater for 3 h = 6 kWh, not 6 kW.
تمرينان آخران: 60 W لمدة 5 h تساوي 300 Wh = 0.3 kWh. ومدفأة 2 kW لمدة 3 h تساوي 6 kWh، لا 6 kW.
Mapping onto HTTP: safe and idempotent
الربط مع HTTP: الآمن (safe) والمتساوي الأثر (idempotent)
Slide 19 makes the abstract concrete: set becomes HTTP PUT, read becomes HTTP GET. Its annotations name the two halves: the arrows are the Protocol (HTTP), and Set and Read on the server edge are the Interface (Web API), because APIs expose methods for clients to interact with the server.
تجعل الشريحة 19 المجرّد ملموساً: الضبط يصبح HTTP PUT، والقراءة تصبح HTTP GET. وتعليقاتها تسمّي النصفين: الأسهم هي Protocol (HTTP)، وSet وRead على حافة الـ server هما Interface (Web API)، لأن الـ APIs تعرض methods يتفاعل بها الـ clients مع الـ server.
Why those two methods? Two HTTP properties (RFC 9110) decide it:
لماذا هاتان الطريقتان تحديداً؟ تحسم ذلك خاصيتان في HTTP (RFC 9110):
- Safe: the method is essentially read-only. The client does not request, and does not expect, any state change on the server. Reading energy changes nothing, so GET fits read.
Safe: الطريقة للقراءة فقط في جوهرها. الـ client لا يطلب ولا يتوقع أي تغيير في حالة الـ server. قراءة الطاقة لا تغيّر شيئاً، فـ GET مناسبة للقراءة.
- Idempotent: the intended effect of N identical requests equals the effect of one. PUT replaces the state with the value sent, so
{"on": true}twice still leaves the lamp on.Idempotent: الأثر المقصود لعدد N من الطلبات المتطابقة يساوي أثر طلب واحد. PUT تستبدل الحالة بالقيمة المرسلة، فإرسال
{"on": true}مرتين يُبقي المصباح مشتعلاً.
| Methodالطريقة (Method) | Lamp useالاستخدام في المصباح | Safeآمن (Safe) | Idempotentمتساوي الأثر (Idempotent) | Retry after a dropped connection?إعادة المحاولة بعد انقطاع الاتصال؟ |
|---|---|---|---|---|
GET | Read energyقراءة الطاقة | Yesنعم | Yesنعم | Yes, harmlessنعم، بلا ضرر |
PUT | Set stateضبط الحالة | No, it changes the lampلا، يغيّر المصباح | Yesنعم | Yes, same final stateنعم، الحالة النهائية نفسها |
DELETE | (not used here)(غير مستخدم هنا) | Noلا | Yesنعم | Yesنعم |
POST | (contrast, see the API lecture)(للمقارنة، انظر محاضرة الـ API) | Noلا | Noلا | Not automatically: a repeat may act twiceليس تلقائياً: التكرار قد ينفّذ العملية مرتين |
This matters on real links. RFC 9110 lets a client automatically repeat an idempotent request if the connection fails before it reads the response, but says it should not automatically retry a non-idempotent one. Edge devices sit on flaky wireless links, so this choice decides whether a retry is harmless or a bug. The API lecture comes back to this when it maps methods to CRUD and POST creates a new item on every call.
هذا مهم على الروابط الحقيقية. يسمح RFC 9110 للـ client بتكرار الطلب idempotent تلقائياً إن انقطع الاتصال قبل قراءة الرد، لكنه يقول إنه لا ينبغي إعادة طلب غير idempotent تلقائياً. أجهزة edge تعمل على روابط لاسلكية غير مستقرة، فهذا الاختيار يحدد هل الإعادة غير ضارة أم خلل. وتعود محاضرة الـ APIs إلى هذا عندما تربط الطرق بـ CRUD، حيث تُنشئ POST عنصراً جديداً في كل استدعاء.
Question 4: the layers, and the server layer
السؤال 4: الطبقات، وطبقة الـ server
Slide 20 answers the last design question for the lamp: one layer. Processing and storage happen in the "server" layer. Then two lines that look alike and are not:
تجيب الشريحة 20 عن سؤال التصميم الأخير للمصباح: طبقة واحدة. المعالجة والتخزين يحدثان في طبقة "server". ثم سطران متشابهان في الشكل وليسا كذلك:
Server component = Program. وServer layer = Program + Processor + Network + Memory + Disk. الـ component هو ما تكتبه، والـ layer هو ما يجب أن توفّره.
Slide 21 restates the layer as the server software plus the compute, storage and communication support, then asks the question the whole course answers: what is the modern name for this server layer? Cloud, fog, or edge, depending on where it is placed. The same program is "edge" on a board next to the lamp and "cloud" in a distant data center. The name belongs to the placement of the layer, not to the code.
تعيد الشريحة 21 صياغة الطبقة بأنها برنامج الـ server زائد دعم الحوسبة والتخزين والاتصال، ثم تطرح السؤال الذي يجيب عنه المقرر كله: ما الاسم الحديث لطبقة الـ server هذه؟ Cloud أو Fog أو Edge، بحسب مكان وضعها. البرنامج نفسه يكون "edge" على لوحة بجانب المصباح، و"cloud" في data center بعيد. الاسم يتبع مكان الطبقة لا الكود.
GET /lamp/energy is part of the interface. It is an endpoint the server exposes, so it belongs to the interface (Web API). It is not the protocol (that is HTTP), not a new component, and not a new layer.
GET /lamp/energy جزء من الـ interface. هو endpoint يعرضه الـ server، فينتمي إلى الـ interface (Web API). ليس الـ protocol (فذلك HTTP)، وليس component جديداً، وليس layer جديدة.
Power versus energy. W is power, Wh and kWh are energy. "100 W × 10 h = 1,000 W" is the slide's own slip. Any answer that reports energy in W is wrong.
القدرة مقابل الطاقة. W قدرة، وWh وkWh طاقة. وعبارة "100 W × 10 h = 1,000 W" هي زلّة الشريحة نفسها. أي جواب يعطي الطاقة بالـ W خاطئ.
Idempotent does not mean safe. PUT is idempotent but not safe, because it changes the lamp. GET is both. Safe is about not changing state; idempotent is about repeats having the same effect as one.
Idempotent لا تعني safe. PUT هي idempotent لكنها ليست safe لأنها تغيّر المصباح. وGET الاثنتان معاً. Safe تعني عدم تغيير الحالة، وidempotent تعني أن التكرار له أثر الطلب الواحد نفسه.
Component versus layer. "The server component includes the processor and disk" is false. The component is the program only; processor, network, memory and disk belong to the layer.
Component مقابل layer. عبارة "الـ server component يشمل المعالج والقرص" خاطئة. الـ component هو البرنامج فقط، أما processor وnetwork وmemory وdisk فتنتمي إلى الـ layer.
Check yourself
اختبر نفسك
The lamp server offers GET /lamp/energy. In system-thinking terms, what is that endpoint?
يقدّم server المصباح GET /lamp/energy. بمصطلحات system thinking، ما هذا الـ endpoint؟
B. An endpoint is an operation the server exposes for clients to call, which is exactly what the interface is. HTTP, which carries the request, is the protocol. The endpoint is not a new box (component) and not a new level of abstraction (layer); the lamp system still has three components and one layer.
الجواب B. الـ endpoint عملية يعرضها الـ server ليستدعيها الـ clients، وهذا بالضبط معنى الـ interface. أما HTTP الذي يحمل الطلب فهو الـ protocol. والـ endpoint ليس صندوقاً جديداً (component) ولا مستوى تجريد جديداً (layer)، فنظام المصباح ما زال ثلاثة مكوّنات وطبقة واحدة.
A 60 W lamp stays on for 5 hours. What should read_energy_usage return?
مصباح 60 W يبقى مشتعلاً 5 ساعات. ماذا يجب أن يعيد read_energy_usage؟
D. E = P × t = 60 W × 5 h = 300 Wh, and 300 ÷ 1000 = 0.3 kWh. A has the right digits and the wrong unit: 300 W is a power, the same slip the slide 18 footnote makes. B and C are conversion errors by a factor of 10.
الجواب D. E = P × t = 60 W × 5 h = 300 Wh، و300 ÷ 1000 = 0.3 kWh. وA أرقامه صحيحة ووحدته خاطئة: 300 W قدرة، وهي الزلّة نفسها في حاشية الشريحة 18. وB وC خطآن في التحويل بمعامل 10.
The client sends PUT /lamp/state with {"on": true} and the connection drops before any reply. What should it do, and why?
يرسل الـ client الطلب PUT /lamp/state مع {"on": true} وينقطع الاتصال قبل أي رد. ماذا يفعل، ولماذا؟
A. PUT replaces the state with the value enclosed, so N identical requests have the same intended effect as one, and RFC 9110 allows an idempotent request to be repeated after a connection failure. B is the classic confusion: not safe means it changes state, which does not forbid a retry; idempotence is the property that governs retries. C is false, POST is neither safe nor idempotent. D is false, GET is safe and does not change the state at all.
الجواب A. PUT تستبدل الحالة بالقيمة المرفقة، فيكون لعدد N من الطلبات المتطابقة الأثر المقصود نفسه لطلب واحد، ويسمح RFC 9110 بتكرار الطلب idempotent بعد انقطاع الاتصال. وB هو الخلط الكلاسيكي: كونها غير safe يعني أنها تغيّر الحالة، وهذا لا يمنع الإعادة، فالخاصية التي تحكم الإعادة هي idempotence. وC خاطئ، فـ POST ليست safe ولا idempotent. وD خاطئ، فـ GET طريقة safe لا تغيّر الحالة إطلاقاً.
True or false style: which statement about the server is correct?
بأسلوب صح أو خطأ: أي عبارة عن الـ server صحيحة؟
C, straight from slides 20 and 21. A and B swap the two definitions, which is exactly how the true/false item is built. D is wrong because cloud, fog and edge name where the layer is placed, not which program runs; the same program can be edge or cloud.
الجواب C، مباشرة من الشريحتين 20 و21. وA وB يتبادلان التعريفين، وهكذا بالضبط يُبنى سؤال صح أو خطأ. وD خاطئ لأن cloud وfog وedge تسمّي مكان الطبقة لا البرنامج الذي يعمل، فالبرنامج نفسه قد يكون edge أو cloud.
Which HTTP method is idempotent but not safe?
أي طريقة HTTP هي idempotent لكنها ليست safe؟
B. PUT changes the lamp (not safe) but sending the same PUT twice leaves the same state (idempotent). DELETE has the same pair of properties. GET is both safe and idempotent. POST is neither. D states the misconception directly: safe methods are a subset of idempotent ones, not the other way round.
الجواب B. PUT تغيّر المصباح (ليست safe) لكن إرسال PUT نفسها مرتين يترك الحالة نفسها (idempotent). وDELETE لها الخاصيتان نفسهما. وGET هي safe وidempotent معاً، وPOST لا هذه ولا تلك. وD ينص على المفهوم الخاطئ صراحة: الطرق الـ safe مجموعة جزئية من الطرق الـ idempotent، لا العكس.