בקשת תיעוד על מבנה ה-API של שליחת סמסים

[שמואל]

@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:

באופן כללי השרת של ימות המשיח מחזיר לי המון פעמים שגיאות עקב תווים לא חוקיים מבחינתו בתוכן הבקשה.

תעשה לכל הטקסט urlencoder כולל לירידת שורה, אני לא חושב שיש הגבלה בכלל על תווים.

@אהרן-שובקס אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:

זה הבעיה שאין קישור...

אתה מאד מועיל בתשובה שלך, אתה יודע?

@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:

אשמח מאוד לקישור אם יש לך!!

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

@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:

אגב בנוגע לתיעוד על הפונקציה הזו שהובאה למעלה (runCampaign) הביאו לי קובץ של תיעוד כללי של ימות - והקטע שמתאר את runCampaign לא מכיל כלל שום אזכור בנוגע להרצת קמפיין ללא טמפלט (אין גם שום אזכור ל-withSMS)
אני משער שזו פונקציה חדשה שנכתבה אחרי שכתבו את התיעוד.. אבל חבל שאין מקום מעודכן

בהחלט, הקובץ לא ממש מעודכן, יש לך כאן תיעוד על כמעט כל האפשרויות שלא מתועדות בקובץ.

[chv]

@שמואל אוה! הנה תשובה
בנוגע לדבריך >

תעשה לכל הטקסט urlencoder כולל לירידת שורה, אני לא חושב שיש הגבלה בכלל על תווים.

כמובן שעשיתי.. אני לא בור לגמרי (חבל שלא ציינתי את זה בשאלה)

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

זהו שממה שכתוב כאן הבנתי שאפשרי ללא צורך בהתאמה מיוחדת, פשוט להשתמש בAPI לשלוח סמס

בהחלט, הקובץ לא ממש מעודכן, יש לך כאן תיעוד על כמעט כל האפשרויות שלא מתועדות בקובץ.

זו התשובה הרצויה.. אכן יש כאן הרבה יותר פירוט. ניכרת השקעה של מי שכתב שם את התיעוד (לא חבל להניח את התיעוד ככה באמצע שום מקום? אפשר לכתוב אותו בצורה יותר מעוצבת, יותר בהירה)
אם כי הקטע הרצוי הוא בדיוק ריק - https://f2.freeivr.co.il/post/32044

בכל אופן תודה

[שמואל]

@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:

כמובן שעשיתי.. אני לא בור לגמרי (חבל שלא ציינתי את זה בשאלה)

לא ידוע לי על תווים שמוגבלים שם מהצד שלנו. - כמובן אם שולחים מקודד urlencode.

אשמח לדוגמא וזמן מדוייק של פניה שלך שנכשלה ואבדוק.

[chv]

@שמואל
בסופו של דבר.. ואחרי כמה שעות ששברתי את הראש.. בדקתי מכיוון אחר את העניין ומה שיצא לי זה שהבאג לא אצל המפרסר של ימות אלא זה מגיע אליו לא בצורה הנכונה
אני מסביר בפירוט. למעוניינים במידע.
אמנם אני לא יכול להוריד פה מידע טכני ממש כי אני לא מבין באמת או יודע לעומק: אבל מה שיצא יצא:

כידוע אחד התווים שמייצגים שורה חדשה זה n\ ובעיקר ב-JS.
כאשר שולחים תווים כאלו בURL - הם חייבים להיות escaped כלומר - שיהיה להם שני בקסלאשים (במקום אחד) כלומר ככה n\\ למה זה חייב שני בקסלאש? יש לזה כמה סיבות (קשור כמובן לפרסור) ואני לא יודע אם אני יכול בכלל להתחיל להסביר אותן.
מה שאני רוצה שיובן זה ש:
אם אכן הגיע הסטרינג n\\ לשרת של ימות - הוא יעשה שורה חדשה
הבעיה היא אכן לשלוח את התו הזה. מה הבעיה? ככה: שהרי אנחנו צריכים לעשות urlencode (נגיד בגאווהסקריפט זה ככהencodeURI('string')) לטקסט של ההודעה עצמה (כדי שיגיע לAPI. כיוון שהתקשורת עם הAPI היא כפרמטר בתוך הURL עצמה ולא כאיזה משהו בתוך הבקשה כגון JSON ב-body.)
כאשר מקודדים תו n\\ לURL - המקודד יהפוך אותו אוטומטית ל(מקודד ל-URL)-n\. זה מצחיק אבל מי שמבין מבין שהמקודד עצמו גם מתייחס לבקסלאשים כפולים ומבין שהוא צריך למחוק אותם כי הם מיותרים ומיועדים רק עבורו שיבין שיש כאן תו מיוחד שהוצרכנו להעביר אליו.. (למי שמבין מה הרעיון של 'להגן' על תווים מיוחדים אלו על ידי בקסלאש כפול)
ובקיצור המקודד הורס לנו את n\\ ועושה לנו אותו n\.
שכאשר מגיע לימות - משגע את המפרסר. ובצדק.

אז עכשיו השאלה - איך להכניס בכוח n\\ לבקשה ל-API ובצורה שתישאר עד שתגיע לימות בריאה ושלימה..
תשובה- אני מצטט משם קוד דוגמא:

var newline = "\n";
$('textarea.myclass').val('this is '+newline+' demo');

כך שבמקרה שלי אני עושה :

let newline = "\\" + "\\n"

ובכל מקום שאני רוצה שורה חדשה (בשלב שאני מקודד סטרינג לתוך הURL) אני דוחף newline

זה פתרון "handy" אני משער שזה הרבה יותר פשוט אבל אם זה עובד אין לי אפילו כוח או עניין לנסות משהו אחר...

ובעצם התשובה @שמואל על דבריך אלו:

לא ידוע לי על תווים שמוגבלים שם מהצד שלנו. - כמובן אם שולחים מקודד urlencode.

כמובן שכן יש תווים ש'מוגבלים מהצד שלכם' אבל הנושא הוא חוסר הבנה (כנראה של שנינו.. לפני שלמדתי הנושא בעל כרחי) מה הכוונה 'מהצד שלנו'.
התווים לא מוגבלים מהצד שלכם אלא מוגבלים מהגורם המכונה URL.. כאשר מתקשרים בדרך הזו של URL (ולא כמו שהזכרתי לדוגמא- שליחת כל הנתונים ב-JSON בתוך הbody) אנחנו מחוייבים גם בצד השולח וגם בצד המקבל - לקודד\לפרסר בהתאמה את הבקשה כURL מה שמחייב אותנו להרבה הגבלות של תווים (לא שהם מוגבלים, פשוט צריך לדעת איך לנווט כדי לשלוח אותם בבקשה)

וואי איזה ארוך

תודה לעוזרים תודה @שמואל

[שמואל]

@chv שליחה בPOST פותרת את רוב הבעיות של ההגבלות של URL.

[chv]

@שמואל אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:

@chv שליחה בPOST פותרת את רוב הבעיות של ההגבלות של URL.

זה לא כ"כ קשור
זה לא יפתור, לדוגמא, את הבעיה שהייתה לי. (אני אפילו לא בודק. אני יודע שככה יהיה)

אגב מה שכמובן שליחה ב-POST פותרת - בלי קשר לבעייה שבשרשור - זה - שאפשר לצרף body... (אני לא חושב שזה לא אפשרי, אגב, לצרף body לבקשת GET. אני חושב שזה נטו סוג של המלצה - לשרת - לא לפרשן כלל את ה-body של בקשות GET)
ובקיצור יהיה נחמד לשדרג את ה-API כך שהתוכן יעבור בגוף הבקשה. כמו המבנה הראוי לAPI תקני

[שמואל]

@chv לא ממש מבין מה זה גוף הבקשה ...
המגבלות שכתבת עליהם, לפחות לפי הבנתי, היו מגבלות של השפה איתה אתה משתמש ולא בעיות שקשורות למבנה הApi עצמו.

[chv]

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

כתבתי לך חוץ מזה - שהייתי מעדיף שהתקשורת מול ה-API לא תהיה URL'ית אלא שהתוכן של הבקשה יועבר על ידי המשתמש דרך ה-body. (כמקובל, ב-JSON וכו') מה ש-א' פותר הרבה דחקים, ב' מאפשר דינמיקה רחבה הרבה יותר של המידע ועיבודו הן על ידי השולח הן על ידי השרת של ימות.

הוספתי שכמובן - רק ב-POST זה יעבוד (כי בקשות GET לא יכולות להכיל body. כלומר יכולות להכיל אבל לא יתייחסו לזה כו')

@שמואל אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:

לא ממש מבין מה זה גוף הבקשה ...

גוף הבקשה == body

[ערוץ הסקרים]

@chv כדי לקודד שורה חדשה ב url כותבים %0A

[chv]

@ערוץ-הסקרים אכן.
אני לא מדבר על צורה שאני מקודד לבד.. זה מקודד אוטומטית על ידי encodeURI של JS