تخزين البيانات على خادم ويب IoT باستخدام طلبات HTTP POST

كما هو موضح في المقال الأول من السلسلة تخزين البيانات التي تم الحصول عليها عن طريق أجهزة إنترنت الأشياء، على الرغم من أن البيانات المحفوظة ينتهي بها الأمر على الخادم MySQL o MariaDB ل ويتم استخدام اللغة PHP لمعالجتها عند الإدخال والإخراج، يحدث تدفق المعلومات بين المعدات الإلكترونية وقاعدة البيانات باستخدام خادم الويب مع من تتواصل وفقا ل بروتوكول HTTP.

في بداية تعريف بروتوكول HTTP كانت هناك استخدامات مماثلة لتلك الموصوفة ولكن الحقيقة هي أنه في النهاية لم يتم استغلالها بالكامل لأسباب مختلفة، جزئيًا تتعلق بالأمن وجزئيًا لأنه لم يتم إحراز تقدم مطلقًا في تحديد بروتوكول أكثر تحديدًا أو أكثر كفاءة، لذلك في الوقت الحاضر، خاصة في الخوادم العامة، الشيء الأكثر شيوعًا هو استخدام الاتصال HTTP ما الذي يجعل أ طلب ما بعد إلى الخادم لتخزين المعلومات أو أ للحصول على لاستعادته، عادةً لعرض صفحة ويب تعرضه وحتى يمكنك التفاعل عليها.

النص الأساسي الذي يتم إرساله إلى الخادم في الطلب HTTP سأعين يتضمن سطرًا بنوع الطلب (سأعين) المسار إلى صفحة الويب التي ستخزن المعلومات وإصدار بروتوكول HTTP; سطر آخر باسم المضيف (والذي يسمح بوجود خوادم افتراضية على نفس الخادم و/أو على نفس عنوان IP) وأخيرًا آخر يحتوي على البيانات المسجلة، مفصولة عن بعضها البعض بعلامة & وعن الأسطر السابقة بواحد فارغ.

في المثال أعلاه، سيحتوي خادم يسمى Polaridad.es على صفحة في /iot/grabar_temperatura لإدارة المعلومات باستخدام الإصدار 1.1 من بروتوكول HTTP

يمكن ملاحظة أنه تم استخدام علامتين & مما يوضح أنه تم تخزين ثلاثة حقول. أسماء الحقول موجودة على يسار علامة المساواة وتم استخدام حرفين فقط لتعريفها. كاسم الحقول (أو المتغيرات، إذا كنت تفضل ذلك) للطلب HTTP وهي ليست مرتبطة بتلك الموجودة في قاعدة البيانات، وليس من المهم بشكل خاص استخدام النصوص الوصفية وعادةً ما يتم اختيار الأسماء المختصرة (حقول مرقمة) لحفظ النص أثناء الاتصال بالخادم وتسريع عملية إرسال البيانات.

البيانات التي يرسلها جهاز إنترنت الأشياء عادةً إلى الخادم هي من النوع الرقمي، وبشكل أساسي الأعداد الصحيحة والكسور العشرية البسيطة. عندما يتم إرسال القيم بتنسيق نصي، كما هو الحال مع المتغير "ne" في المثال، قد تنشأ ظروف غير مواتية يمكن حلها، حسب الحالة، بنجاح وسهولة أكثر أو أقل. في هذه المناسبة، يتم استخدام علامات الجمع (+) للفصل بين الكلمات، واستبدال المسافات التي قد تؤدي إلى تغيير الكلمة طلب ما بعد. الطريقة العامة لإرسال البيانات التي تحل معظم الحالات هي الإشارة إلى الرمز السداسي العشري للأحرف، مسبوقًا بعلامة النسبة المئوية (%) منطقيًا، لا يُنصح باستخدام هذا المورد إلا عندما يكون ما تم ترميزه مشكلة منذ طول يتم زيادة ما يتم إرساله، الأمر الذي يتطلب عمومًا المزيد من الموارد، على الرغم من أن حجمها صغير جدًا بالتأكيد.

على الرغم من أنه من الممكن تشغيل أ خادم الويب بالنسبة لإنترنت الأشياء فقط مع المعلومات الواردة في المثال السابق، تقوم العديد من الخوادم، وخاصة العامة منها، بإضافة بيانات أخرى إلى استعلام POST (للأسف لا يقتصر ذلك دائمًا على البروتوكول)، المثال أدناه يتوافق مع طلب النشر الذي طلبه البئر -الخادم المعروف.عام لإنترنت الأشياء الكلام.

بالإضافة إلى بعض البيانات الشخصية مثل X-THINGSPEAKAPIKEY (والذي يتوافق مع معرف كل عميل) في المثال السابق يمكنك أن ترى أن هناك رؤوس أخرى تضيف المزيد من المعلومات إلى الطلب.

كيفية استخدام رأس في طلب ما بعد يتكون ببساطة من كتابة اسمه وعلامة النقطتين (:) ومساحة فارغة والقيمة التي تريد تخصيصها لها.

من أجل اختبار طلبات POST إلى خادم الويب قبل إكمال تكوين المكونات الأخرى، يمكن إنشاء اتصال بالخادم وإرسال البيانات يدويًا. على سبيل المثال، على جهاز كمبيوتر يعمل بنظام Linux، سيكون ذلك كافيًا للاستخدام telnet polaridad.es 80 حيث Polaridad.es هو اسم الخادم و80 هو رقم المنفذ الذي تستجيب عليه الخدمة. HTTP.

يمكن استخدام الأداة المشتركة بين الأنظمة الأساسية على Linux أو Windows أو OS المعجون، والذي تم الحديث عنه في المقال التحكم في أجهزة UART التسلسلية من الكمبيوتر، لإجراء الاتصال دون استخدام وحدة التحكم.

في ما يلي قائمة رؤوس HTTP هناك معظم تلك التي يمكن أن تكون مفيدة لـ طلب ما بعد إلى خادم الويب لإنترنت الأشياء.

• Accept يتم استخدامه للإشارة إلى النوع MIME الذي يتوقع الطلب أن يستخدمه الخادم في الاستجابة. يتم التعبير عنها ك tipo/subtipo والتي يمكن تعميمها باستخدام العلامة النجمية (*) كعلامة بدل، على سبيل المثال */* للإشارة إلى أي أو tipo/* للإشارة إلى جميع الأنواع الفرعية من tipo

  الأكثر استخدامًا هي:

  • text/plain على الرغم من أنها الأكثر أساسية، إلا أنها الأكثر استخدامًا. ويتوقع أن يقوم الخادم بإرجاع استجابة نصية بسيطة (عادية) كافية للإخطار بأن المعاملة قد تمت بشكل صحيح وعلى الأكثر إضافة معلومات ملحقة مثل رقم طلب البيانات المسجلة ونتيجة المقارنة وتاريخ المعاملة. الخادم…

  • application/xml o text/xml انتظر حتى يستجيب الخادم للطلب بالتنسيق XML. معنى الاختيار text بدلا من application يسمح بقراءة "إنسانية" أسهل (مقابل "تلقائية"). هذه الازدواجية سوف تظهر في الآخرين أنواع MIME ولكن الاتجاه المستقبلي للمعيار هو المفضل application أمام text الشكل XML يسمح بتنظيم الاستجابة التي تحتوي على الكثير من البيانات بطريقة قوية للغاية، والعيب هو أنها تضيف الكثير من الحيل إلى البيانات الصافية، مما يجعل الاستجابة تستهلك أكثر من اللازم، وبالتالي تتطلب المزيد من عرض النطاق الترددي وربما أكثر الذاكرة في جهاز إنترنت الأشياء لمعالجتها.

  • text/html يستخدم عندما تكون استجابة الخادم HTML مشفر كنص عادي (نص عادي) عادةً ما يقوم بتنسيق الاستجابة. وبما أن الأمر يتعلق بتخزين البيانات وتصل الاستجابة إلى جهاز صغير بدون موارد كثيرة، فمن غير الشائع استخدام هذا النوع.

  • application/xhtml+xml في الأساس هو الإصدار XHTML (HTML كما XML صالح) للمعلومات الواردة في القسم السابق.

  • application/json يتم استخدامه بشكل أكبر عندما تحتوي استجابة الخادم على عدة بيانات بما في ذلك بنية أكثر أو أقل تعقيدًا. التنسيق JSON حصة مع الشكل XML بنية صلبة وتضيف ميزة كونها أكثر إيجازا في النص الذي تضيفه البنية.

• Accept-Charset يحدد ترميز النص المطلوب استخدامه في الاستجابة. لترميز الأحرف اللاتينية، UTF-8، الأكثر اكتمالا، ISO-8859 15، والذي يتضمن علامة اليورو (€) و ISO-8859 1، وهو الأكثر أساسية.

• Accept-Encoding يشير إلى التنسيق الذي يمكن من خلاله تشفير استجابة الخادم. يعمل بشكل أساسي على الإشارة إلى نوع الضغط. بعض من الأكثر شيوعا هي gzip deflate (والتي يمكن تحديدها بمزيد من التفصيل مع deflate-raw o deflate-http) ليس من الشائع استخدامه في الأجهزة الصغيرة المتصلة بإنترنت الأشياء لأنه يتطلب استهلاكًا معينًا للموارد (الذاكرة ووقت المعالجة) التي عادة ما تكون شحيحة في هذا النوع من المعدات. ليس من الضروري الإشارة إلى عدم استخدام الضغط مع Accept-Encoding: identity لأن مثل هذا الظرف يعتبر افتراضيا.

• Accept-Language يعبر عن اللغة التي يمكن استخدامها في الإجابة. على سبيل المثال، سيتم تحديد اللغة الإسبانية لإسبانيا كـ es-ES أو الإنجليزية للولايات المتحدة الأمريكية مثل en-US

• Connection يتم استخدامه لتحديد ما يجب القيام به مع الاتصال الذي تم إنشاؤه بين العميل (جهاز إنترنت الأشياء) و خادم الويب بمجرد استلام البيانات. تستخدم عادة مع القيمة close في التنسيق Connection: close للإشارة إلى أنه يجب إغلاق الاتصال بعد الرد على العميل.

• Content-Length يسمح لك بتحديد عدد البايتات التي يشغلها جزء الطلب الذي يحتوي على البيانات، وهو الجزء الذي يلي الرؤوس ويفصل بينها سطر فارغ. إنه مفيد للغاية لأنه يعمل على التحقق من سلامة المعلومات المرسلة؛ وإذا لم يقم بقياس ما تم الإعلان عنه، فلا يتم تخزينه لأنه يعتبر أنه لم يصل بشكل صحيح. عادة ما تكون مطلوبة من قبل معظم خوادم إنترنت الأشياء العامة.

• Content-Type يعمل على الإشارة إلى نوع التمثيل الصامت والتي يتم من خلالها تشفير المعلومات المرسلة إلى الخادم. وعادة ما تستخدم الأنواع text/html عندما يتم التعبير عن البيانات المرسلة إلى الخادم كقائمة بسيطة من القيم (شيء مثل a=3.6&b=4.8) Y application/jsonrequest (والذي سيكون معادلاً للنوع application/json الذي تحدث عنه في Accept) عندما يكون من الضروري إنشاء بنية أكثر تعقيدًا، ولكن يمكن إرسال أي مما يلي قائمة أنواع MIME.

• Cookie يتم استخدامه لإضافة معرف جلسة يمكن من خلاله الحفاظ على سلسلة من عمليات النقل (استعلام، استجابة، استعلام...) وهي أكثر تعقيدًا من طلب واحد يتم من خلاله إرسال بعض البيانات ذات الصلة ولكن يتم الحصول عليها في أوقات مختلفة.

جدول المحتويات


• Referer عنوان URL الذي أنشأ طلب POST، على سبيل المثال صفحة الويب التي تم إرساله منها. وفي حالة استخدامه لإنترنت الأشياء، فإنه لا يضيف معلومات ذات صلة حيث يتم إرسال المعلومات مباشرة، دون صفحة سابقة، لذلك لا يتم استخدامها بشكل متكرر.

• User-Agent يقوم بالإبلاغ عن الجهاز الذي يقوم بالطلب. في حركة مرور الويب العادية، يسمح المتصفح المستخدم في إنترنت الأشياء للخادم بالإشارة إلى نوع الجهاز الإلكتروني الذي يقدم الطلب. يتيح تعريف نفسه للخادم تنسيق الاستجابة بشكل مختلف في كل حالة، على سبيل المثال، إعادة صفحة ويب معقدة إلى المتصفح وبعض بيانات التحذير إلى جهاز إنترنت الأشياء الصغير.

من الممكن تحديد قائمة خيارات مفصولة بفواصل بدلاً من قيمة واحدة في الرؤوس للإشارة إلى دعم عدة قيم مختلفة في وقت واحد. يمكن أن يكون لهذه القيم ترتيب أولوية يتم التعبير عنه وفقًا لمعامل الجودة q لكل منها. يتم فصل معاملات الجودة بفاصلة منقوطة (؛) ويمكن أيضًا استخدام العلامات النجمية (*) للإشارة إلى أي نوع أو نوع فرعي.

Accept: text/plain,text/xml,application/json;q=0.8,text/*;q=0.9,application/json

في المثال السابق أولوية التنسيق JSON الأكبر (0.9) هو النص العادي والنص المنسق. XML، والتي تلبي المواصفات text/*، أصغر (0.8) ومتساوي بينهما. إذا كان ذلك ممكنًا، يجب أن يتفاعل الخادم عن طريق تشفير الاستجابة كـ JSON.

في المثال التالي لطلب POST أكثر اكتمالا، يتم الوصول إلى صفحة /iot/grabar_temperatura للخادم المسمى Polaridad.es باستخدام الإصدار 1.1 من بروتوكول HTTP. يقوم العميل، المسمى Sensoreitor-2000، بإرسال البيانات المشفرة JSON، توقع الرد كنص عادي بالتنسيق UTF-8 استخدام الإسبانية من إسبانيا دون استخدام الضغط، والذي، بالمناسبة، ليس من الضروري الإشارة إليه. تشغل البيانات المرسلة إلى الخادم 65 بايت. عند إرسال الرد سيتم إغلاق الاتصال بين العميل والخادم.

المقالة التالية توضح كيفية تكوين قاعدة بيانات MySQL لتخزين المعلومات المرسلة بواسطة كائنات إنترنت الأشياء