אחסן נתונים בשרת אינטרנט של IoT באמצעות בקשות HTTP POST

כפי שהוסבר במאמר הראשון של הסדרה לאחסן נתונים שהושגו על ידי מכשירי האינטרנט של הדברים, למרות שהנתונים שנשמרים מגיעים בסופו של דבר לשרת MySQL o מריאד ומשתמשים בשפה PHP כדי לתפעל אותם בקלט ובפלט, זרימת המידע בין הציוד האלקטרוני למסד הנתונים מתרחשת באמצעות א שרת אינטרנט עם מי אתה מתקשר לפי פרוטוקול HTTP.

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

הטקסט הבסיסי ביותר שנשלח לשרת בבקשה HTTP POST כולל שורה עם סוג הבקשה (POST) הנתיב לדף האינטרנט שיאחסן את המידע ואת הגרסה של ה- פרוטוקול HTTP; שורה נוספת עם שם המארח (המאפשרת שרתים וירטואליים באותו שרת ו/או באותה כתובת IP) ולבסוף עוד שורה המכילה את הנתונים שנרשמו, מופרדים זה מזה בסימן & ומהשורות הקודמות באחד רֵיק.

בדוגמה שלמעלה, שרת בשם polaridad.es יכיל עמוד ב-/iot/grabar_temperatura לניהול המידע באמצעות גרסה 1.1 של פרוטוקול HTTP

ניתן לראות כי נעשה שימוש בסימנים שניים ואשר מראה כי מאוחסנים שלושה שדות. שם השדות נמצא משמאל לסימן השוויון ורק שתי אותיות שימשו להגדרתם. כשם השדות (או המשתנים, אם אתה מעדיף) של הבקשה HTTP הם לא קשורים לאלה שבבסיס הנתונים, לא חשוב במיוחד להשתמש בטקסטים תיאוריים ובדרך כלל בוחרים שמות קצרים (שדות ממוספרים אפילו) כדי לשמור טקסט בתקשורת עם השרת ולהאיץ את תהליך שליחת הנתונים.

הנתונים שמכשיר IoT שולח בדרך כלל לשרת הם מסוג מספרי, בעיקר מספרים שלמים ועשרונים פשוטים. כאשר ערכים נשלחים בפורמט טקסט, כמו במקרה של המשתנה "ne" בדוגמה, עלולות להיווצר נסיבות שליליות שניתן לפתור, בהתאם למקרה, בהצלחה ובקלות פחות או יותר. בהזדמנות זו, סימני פלוס (+) משמשים להפרדת מילים, תוך החלפת רווחים שאחרת ישנו את בקשת פוסט. דרך גנרית לשליחת הנתונים שפותרת את רוב המקרים היא על ידי ציון הקוד ההקסדצימלי של התווים, לפניו סימן האחוז (%) מבחינה לוגית, לא כדאי להשתמש במשאב זה אלא כאשר מה שמקודד בעייתי שכן האורך של מה שנשלח גדל, מה שבדרך כלל דורש יותר משאבים, אם כי הוא בהחלט קטן מאוד בגודלו.

למרות שניתן להפעיל א שרת אינטרנט עבור האינטרנט של הדברים רק עם המידע מהדוגמה הקודמת, שרתים רבים, במיוחד ציבוריים, מוסיפים נתונים אחרים לשאילתת ה-POST (לצערי לא תמיד מוגבל לפרוטוקול). הדוגמה למטה מתאימה לבקשת הפוסט המבוקשת על ידי הבאר. -שרת ידוע. ציבורי עבור האינטרנט של הדברים דבר דבר.

בנוסף לכמה נתונים אישיים, כגון X-THINGSPEAKAPIKEY (והמתאים למזהה של כל לקוח) בדוגמה הקודמת ניתן לראות שיש כותרות נוספות שמוסיפות מידע נוסף לבקשה.

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

על מנת לבדוק בקשות POST לשרת האינטרנט לפני השלמת התצורה של שאר הרכיבים, ניתן ליצור חיבור לשרת ולשלוח את הנתונים באופן ידני. לדוגמה, במחשב לינוקס זה יהיה מספיק לשימוש 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 מאפשרת מבנה של תגובה שמכילה הרבה נתונים בצורה מאוד סולידית, החיסרון הוא שהוא מוסיף הרבה אומנות לנתונים נטו, מה שגורם לתגובה לתפוס יותר מהנדרש, ולכן דורש יותר רוחב פס וכנראה יותר זיכרון במכשיר ה-IoT כדי לעבד אותו.

  • 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 או האנגלית של ארצות הברית של אמריקה as en-US

• Connection הוא משמש כדי לציין מה צריך לעשות עם החיבור שנוצר בין הלקוח (מכשיר ה-IoT) לבין שרת אינטרנט לאחר קבלת הנתונים. משמש בדרך כלל עם הערך close בפורמט Connection: close כדי לציין שיש לסגור את החיבור לאחר מענה ללקוח.

• Content-Length זה מאפשר לך לציין את מספר הבתים התפוס על ידי החלק של הבקשה שמכיל את הנתונים, שהוא זה שאחרי הכותרות ומופרדים בשורה ריקה. זה מאוד שימושי מכיוון שהוא משמש לאימות שלמות המידע שנשלח; אם הוא לא מודד את מה שהוכרז, הוא לא נשמר מאחר ונחשב שלא הגיע כמו שצריך. זה בדרך כלל נדרש על ידי רוב שרתי ה-IoT הציבוריים.

• Content-Type זה משמש כדי לציין את סוג MIME באמצעותו מקודד המידע שנשלח לשרת. בדרך כלל משתמשים בסוגים text/html כאשר הנתונים הנשלחים לשרת באים לידי ביטוי כרשימה פשוטה של ​​ערכים (משהו כמו a=3.6&b=4.8) ו application/jsonrequest (שזה יהיה המקביל לסוג application/json שעליו מדברים ב Accept) כאשר יש צורך במבנה מורכב יותר, אך ניתן לשלוח כל אחד מהדברים הבאים רשימה של סוגי MIME.

• Cookie הוא משמש להוספת מזהה הפעלה שבאמצעותו ניתן לתחזק שרשרת העברות (שאילתה, תגובה, שאילתה...) שהיא מורכבת יותר מבקשה בודדת שאיתה ניתן לשלוח נתונים קשורים מסוימים אך מתקבלת בזמנים שונים.

תוכן עניינים


• Referer כתובת האתר שמקורה בבקשת ה-POST, למשל דף האינטרנט שממנו היא נשלחה. במקרה של שימוש ל-IoT, הוא אינו מוסיף מידע רלוונטי מכיוון שהמידע נשלח ישירות, ללא עמוד קודם, כך שלא נעשה בו שימוש תכוף.

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

אפשר לציין רשימה מופרדת בפסיקים של אפשרויות במקום ערך בודד בכותרות כדי לציין שמספר ערכים שונים נתמכים בו זמנית. לערכים אלו יכולים להיות סדר עדיפות שמתבטא לפי מקדם איכות 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 לאחסון מידע שנשלח על ידי אובייקטי IoT