🍿 CornPop

submit in HTML

8 min read

لما بتيجي تشتري حاجة أونلاين، بتملى عنوانك ورقم الكريديت كارد بتاعك، وبعدين بتدوس على زرار “Order” عشان تأكد الأوردر. وبما إنك بتتعلم أكتر عن الـ front-end development، ممكن تكون بتسأل نفسك إيه اللي بيحصل بالظبط لما بتدوس على زرار الـ Order ده.

في المقال ده، هنعرف إيه اللي بيحصل لما الـ forms بيتعمل لها submit في الـ web browser.

دايرة الـ Request والـ Response بين الـ Browser والـ Server

زي ما عرفت، الـ web browser بيتواصل مع الـ web server عن طريق حاجة اسمها HTTP request response cycle واتكلمنا قبل كدا عن HTTP.

  • يعني إيه؟ يعني الـ browser بيبعت requests للـ server، والـ server بيرد عليه بـ response.
  • إيه نوع الـ requests دي؟ لحد دلوقتي، النوع الأساسي من الـ requests اللي اتعاملت معاها كانت لطلب resources زي ملفات HTML، صور، ملفات CSS، وملفات JavaScript.

بس مش بس كده، ممكن كمان تبعت data جوه الـ request نفسه. هي دي الطريقة اللي الـ forms بتبعت بيها الداتا للـ web server.

إزاي الـ Forms بتبعت الداتا للـ Server؟

فيه طريقتين أساسيتين الـ form يقدر يبعت بيهم الداتا دي:

  1. طريقة الـ HTTP GET method
  2. طريقة الـ HTTP POST method

بتقدر تحدد الطريقة اللي الـ form هيستخدمها عن طريق الـ method attribute جوه الـ form element نفسه.

تعالى نشوف مثال لـ form ونشوف إزاي الداتا بتتبعت بالطريقتين دول.

  • المثال: login form بسيط، بياخد username و password. وفيه زرار Login عشان يعمل submit للـ form للـ web server.

طريقة الـ GET

إيه اللي هيحصل لو الـ method attribute متظبط على GET؟

  1. لما تدوس على زرار الـ Login، الداتا بتاعة الـ form بتتبعت كجزء من الـ URL بتاع الـ request.
  2. يعني الداتا بتاعة اليوزر بتتلزق في آخر الـ URL فوق في الـ navigation bar بتاع الـ browser.
  3. الـ web server بيستقبل الـ HTTP GET request ده، وبياخد الداتا بتاعة الـ form من الـ URL.

مشاكل طريقة الـ GET

صحيح دي طريقة سهلة لبعت الداتا، بس فيها تلات مشاكل أساسية:

  1. حدود طول الـ URL في الـ Browser:
    • طول الـ URL محدود بحوالي 2000 حرف، وده بيختلف حسب الـ web browser اللي بتستخدمه.
    • فيه browsers بتسمح بأكتر، بس مفيش ثبات بينهم.
    • المشكلة: لو الـ form بتاعك كبير، ممكن شوية داتا تضيع وهي بتتبعت بطريقة الـ GET للـ web server.
  2. حدود طول الـ URL في الـ Server:
    • طول الـ requested URL برضه ليه حدود على بعض الـ web servers.
    • أشهر web server software زي Apache web server أو Nginx، ليهم default limit حوالي 4096 حرف.
    • المشكلة: برضه، لو الـ form كبير، فيه داتا ممكن تضيع.
  3. الـ Security:
    • عشان الداتا بتبقى جزء من الـ URL، ده معناه إنها بتتخزن في الـ web browser history بتاعك، وممكن كمان في الـ request logs على الـ web server.
    • المشكلة: لو بتبعت معلومات شخصية زي عنوان أو رقم كارت ائتمان، دي تعتبر مخاطرة كبيرة على الخصوصية والأمان.

طريقة الـ POST

طيب، تعالى نشوف إيه اللي بيحصل لو ظبطنا الـ method attribute على post؟

  1. لما الـ form بيتعمله submit باستخدام الـ post method، الداتا بتتحط جوه الـ content بتاع الـ HTTP request نفسه (في الـ body).
  2. لما بتدوس زرار الـ submit، الـ browser بيبعت HTTP post request والداتا جواه في الـ body بتاع الـ request.

الأمان في الـ POST

  • طريقة الـ HTTP post بتعتبر آمن أكتر من طريقة الـ HTTP GET.
  • بس خلي بالك، الداتا دي لسه ممكن حد تالت يقراها وهو بيراقب الـ HTTP request.
  • عشان تأمن الموضوع ده تمامًا، بنستخدم HTTPS عشان يعمل encrypt للداتا، بحيث إن اللي بيبعت (sender) واللي بيستقبل (receiver) بس هما اللي يقدروا يفهموها.

الـ Server بيرد إزاي؟

لما الـ web server يستقبل الـ request، بيعمل له process ويبعتلك HTTP response.

  • لو الـ request نجح: الـ response ده غالبًا بيوجه الـ web browser لصفحة جديدة.
  • لو حصل errors: فيه طرق كتير ممكن الصفحة تتعامل بيها مع الموضوع ده.

دلوقتي المفروض بقيت فاهم إزاي الـ forms بتتبعت للـ web servers، والفرق بين GET و POST.

تفاصيل أكتر عن إرسال الـ Forms (Submit)

انت لسه متعلم إزاي الـ forms بتتبعت للـ web servers والفرق بين Get و Post. في الجزء ده، هنبني على المعلومات دي وهنتعلم أكتر عن الـ Submit.

عمليات الـ Form submissions دي جزء أساسي من الويب. تقريبا كل المواقع بتستخدم forms، من أول شراء المنتجات أونلاين لحد طلب الأكل دليفري. لما بتدوس على زرار الـ login في أي موقع، ده بيبعت الـ username والـ password بتوعك لـ web server عشان يسجلك دخول.

الـ Attributes الأساسية: action و method

زي ما عرفت، انت بتضيف form لصفحة الويب بتاعتك باستخدام الـ <form> tag.

<form> 
</form>

بس إزاي الـ form ده بيتعمله submit، ده بيتحدد عن طريق اتنين attributes مهمين جدًا: action و method.

الـ action Attribute

  • وظيفته: بيحدد العنوان (الـ web address) اللي الـ form لازم يتبعتله. العنوان ده هو مكان الـ server-side code اللي هيعمل process للـ request.
<form action="/login"> 
</form>

  • أنواعه: مهم تعرف إن الـ action ده ممكن يكون:

    • URL كامل: زي https://meta.com
    • Absolute path: زي /login (بيبدأ بـ /)
    • Relative path: زي login (مبيبدأش بـ /)

  • إزاي بيشتغل الـ Absolute Path:

    • الـ absolute path، اللي بيبدأ بـ forward slash (/)، بيستخدم الـ base address بتاع الموقع الحالي (مثلا https://meta.com) ويضيف عليه الـ absolute path.
    • مثال: لو الـ absolute path هو /login والعنوان الحالي https://meta.com، الـ form هيتبعت لـ https://meta.com/login.
    • مثال تاني: لو العنوان الحالي https://meta.com/company-info/ والـ absolute path هو /login، الـ form برضه هيتبعت لـ https://meta.com/login (بيرجع للـ base address).

  • إزاي بيشتغل الـ Relative Path:

    • الـ relative path بيستخدم العنوان الحالي ويضيف عليه الـ relative path.
    • مثال: لو الـ browser دلوقتي فاتح صفحة https://meta.com/company-info/، والـ relative path متظبط على login، الـ form هيتبعت لـ https://meta.com/company-info/login.

الـ method Attribute

  • وظيفته: بيحدد أنهي HTTP method هيستخدم عشان يعمل submit للـ form؛ GET ولا POST.
<form method="get"> 
</form> 
<form method="post"> 
</form>
  • الـ Default: لو محطتش الـ method attribute، الـ form هيستخدم طريقة الـ HTTP GET كـ default.

ملخص سريع للفرق بين GET و POST

  • الـ HTTP GET: الداتا اللي في الـ fields بتاعته بتتعملها encoding جوه الـ URL.
  • الـ HTTP POST: الداتا بتتبعت كجزء من الـ HTTP request body.

لما الـ web server يستقبل الـ request، بيعمل process للداتا دي ويبعتلك HTTP response. الـ response ده بيوضح نتيجة الـ submission، اللي ممكن تكون نجحت (successful) أو فشلت (fail) بسبب داتا غلط أو مش مظبوطة.

طرق تانية لبعت الداتا غير الـ Forms

بس مهم ليك كـ front-end developer، إنك تعرف إن الـ forms مش هي الطريقة الوحيدة لبعت الداتا للـ web server.

لما تتعلم أكتر عن JavaScript والـ front-end libraries، هتكتشف إن الـ developers ساعات كتير بيبعتوا HTTP requests على طول عن طريق الكود، وبيبعتوا الداتا كجزء من الـ HTTP request body في format معين اسمه JavaScript Object Notation، أو JSON.

علاقته بـ REST API

تعالى نربط الكلام اللي فات بتاع الـ Forms (GET و POST) بمفهوم الـ REST API.

بص يا سيدي، الموضوع كله قايم على بروتوكول HTTP. ده البروتوكول الأساسي اللي الـ clients (زي الـ browser بتاعك) بتستخدمه عشان تتكلم مع الـ servers.

إيه علاقة ده بالـ Forms والـ REST API؟

  1. الأساس المشترك (HTTP Methods والـ URL):

    • الـ Forms: لما بتعمل submit لـ form، الـ browser بتاعك بيعمل HTTP request للـ URL اللي متحدد في الـ action attribute، وبيستخدم الـ HTTP Method اللي متحدد في الـ method attribute (غالبًا GET أو POST).
    • الـ REST API: هي برضه عبارة عن مجموعة من الـ URLs (بنسميها endpoints) اللي الـ server بيعرضها عشان الـ clients تقدر تتفاعل معاها. التفاعل ده بيتم عن طريق HTTP requests باستخدام HTTP Methods مختلفة زي GET, POST, PUT, DELETE, وهكذا.

  2. نفس الأفعال (Methods) بس استخدام أوسع:

    • الـ GET: في الـ Forms، بتستخدمها غالبًا عشان تطلب صفحة أو بيانات بناءً على input بسيط (زي البحث). في الـ REST API، الـ GET بتستخدم بشكل أساسي عشان تطلب/تقرا بيانات (Read) من resource معين (زي هاتلي بيانات اليوزر رقم 5).
    • الـ POST: في الـ Forms، بتستخدمها عشان تبعت بيانات جديدة للـ server عشان يعمل بيها حاجة (زي تسجيل يوزر جديد، أو إضافة تعليق). في الـ REST API، الـ POST غالبًا بتستخدم عشان تنشئ resource جديد (Create) على الـ server (زي إضافة منتج جديد لقاعدة البيانات).

  3. الـ URL هو العنوان:

    • الـ action في الـ Form: ده الـ URL اللي الـ browser هيبعتله الداتا بتاعت الـ form.
    • الـ Endpoint في الـ REST API: ده الـ URL اللي الـ client (ممكن يكون browser، موبايل أبلكيشن، أو حتى server تاني) هيبعتله الـ request عشان يتفاعل مع resource معين.

طيب إيه الفرق الجوهري أو التطور؟

  • الـ Forms: دي الطريقة التقليدية المخصصة لتفاعل المستخدم مع صفحة الويب عشان يبعت داتا للـ server، وغالبًا الرد بيكون صفحة HTML جديدة الـ browser بيعرضها. الداتا بتتبعت بـ format اسمه application/x-www-form-urlencoded (لو GET أو POST عادي) أو multipart/form-data (لو فيه فايلات بتترفع).
  • الـ REST API: دي طريقة أكتر تنظيمًا ومرونة لتفاعل البرامج والتطبيقات مع بعضها. مش شرط الـ client يكون browser، ومش شرط الرد يكون صفحة HTML.
    • الـ REST API بتستخدم مجموعة أوسع من الـ HTTP Methods (GET, POST, PUT, DELETE, PATCH…) عشان تعبر بوضوح عن نوع العملية المطلوبة على الـ resource (Read, Create, Update, Delete).
    • الرد من الـ REST API غالبًا بيكون بيانات (Data) في format معين زي JSON، عشان الـ client application يقدر يستخدمها ويعرضها بطريقته (زي في الـ Single Page Applications أو الموبايل أبلكيشنز).
    • بتسمح بفصل واضح بين الـ client (Front-end) والـ server (Back-end).

الخلاصة:

الـ Forms وطريقة شغلها بـ GET و POST هما تطبيق مبكر ومباشر لمبادئ الـ HTTP لتبادل البيانات بين الـ browser والـ server. الـ REST API هي تطور وتصميم معماري (Architectural Style) بيعتمد على نفس مبادئ الـ HTTP (URLs, Methods) ولكن بشكل أكتر تنظيمًا وقابلية للتوسع عشان يسمح للتطبيقات المختلفة (مش بس الـ browser) إنها تتكلم مع بعضها وتبعت وتستقبل بيانات (غالبًا JSON) بطريقة standardised.

فكر فيها كده: الـ action بتاع الـ Form ممكن يكون بيشاور على endpoint في REST API معمول مخصوص عشان يستقبل الداتا دي من الـ form.

Graph View

Backlinks