בקשת תיעוד על מבנה ה-API של שליחת סמסים
-
פוסט זה נמחק! -
@chv
תוכל להשתמש עם הAPI של האתר sms של ימות זה אגב יותר זול נראה לי והAPI יותר בנוי
הבעיה ששם אין בדיקה אם זה מספר כשר או לא ועולה לך גם על מספר כשר אפי' שזה לא נשלח כמובן -
@אהרן-שובקס אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
הAPI של האתר sms של ימות
אשמח מאוד לקישור אם יש לך!!אגב בנוגע לתיעוד על הפונקציה הזו שהובאה למעלה (
runCampaign) הביאו לי קובץ של תיעוד כללי של ימות - והקטע שמתאר אתrunCampaignלא מכיל כלל שום אזכור בנוגע להרצת קמפיין ללא טמפלט (אין גם שום אזכור ל-withSMS)
אני משער שזו פונקציה חדשה שנכתבה אחרי שכתבו את התיעוד.. אבל חבל שאין מקום מעודכן -
@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
אשמח מאוד לקישור אם יש לך!!
זה הבעיה שאין קישור...
-
פוסט זה נמחק! -
@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
באופן כללי השרת של ימות המשיח מחזיר לי המון פעמים שגיאות עקב תווים לא חוקיים מבחינתו בתוכן הבקשה.
תעשה לכל הטקסט urlencoder כולל לירידת שורה, אני לא חושב שיש הגבלה בכלל על תווים.
@אהרן-שובקס אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
זה הבעיה שאין קישור...
אתה מאד מועיל בתשובה שלך, אתה יודע?
@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
אשמח מאוד לקישור אם יש לך!!
מערכת סמסים שהיא רק לסמסים ניתנת מול שירות לקוחות, והיא מערכת נפרדת לחלוטין. אם אתה חושב שאתה צריך את זה תוכל לפנות לשירות לקוחות.
@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
אגב בנוגע לתיעוד על הפונקציה הזו שהובאה למעלה (runCampaign) הביאו לי קובץ של תיעוד כללי של ימות - והקטע שמתאר את runCampaign לא מכיל כלל שום אזכור בנוגע להרצת קמפיין ללא טמפלט (אין גם שום אזכור ל-withSMS)
אני משער שזו פונקציה חדשה שנכתבה אחרי שכתבו את התיעוד.. אבל חבל שאין מקום מעודכןבהחלט, הקובץ לא ממש מעודכן, יש לך כאן תיעוד על כמעט כל האפשרויות שלא מתועדות בקובץ.
-
@שמואל אוה! הנה תשובה
בנוגע לדבריך >תעשה לכל הטקסט urlencoder כולל לירידת שורה, אני לא חושב שיש הגבלה בכלל על תווים.
כמובן שעשיתי.. אני לא בור לגמרי (חבל שלא ציינתי את זה בשאלה)
מערכת סמסים שהיא רק לסמסים ניתנת מול שירות לקוחות, והיא מערכת נפרדת לחלוטין. אם אתה חושב שאתה צריך את זה תוכל לפנות לשירות לקוחות.
זהו שממה שכתוב כאן הבנתי שאפשרי ללא צורך בהתאמה מיוחדת, פשוט להשתמש בAPI לשלוח סמס
בהחלט, הקובץ לא ממש מעודכן, יש לך כאן תיעוד על כמעט כל האפשרויות שלא מתועדות בקובץ.
זו התשובה הרצויה.. אכן יש כאן הרבה יותר פירוט. ניכרת השקעה של מי שכתב שם את התיעוד (לא חבל להניח את התיעוד ככה באמצע שום מקום? אפשר לכתוב אותו בצורה יותר מעוצבת, יותר בהירה)
אם כי הקטע הרצוי הוא בדיוק ריק - https://f2.freeivr.co.il/post/32044בכל אופן תודה
-
@chv אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
כמובן שעשיתי.. אני לא בור לגמרי (חבל שלא ציינתי את זה בשאלה)
לא ידוע לי על תווים שמוגבלים שם מהצד שלנו. - כמובן אם שולחים מקודד urlencode.
אשמח לדוגמא וזמן מדוייק של פניה שלך שנכשלה ואבדוק.
-
@שמואל
בסופו של דבר.. ואחרי כמה שעות ששברתי את הראש.. בדקתי מכיוון אחר את העניין ומה שיצא לי זה שהבאג לא אצל המפרסר של ימות אלא זה מגיע אליו לא בצורה הנכונה
אני מסביר בפירוט. למעוניינים במידע.
אמנם אני לא יכול להוריד פה מידע טכני ממש כי אני לא מבין באמת או יודע לעומק: אבל מה שיצא יצא:כידוע אחד התווים שמייצגים שורה חדשה זה
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.
-
@שמואל אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
@chv שליחה בPOST פותרת את רוב הבעיות של ההגבלות של URL.
זה לא כ"כ קשור
זה לא יפתור, לדוגמא, את הבעיה שהייתה לי. (אני אפילו לא בודק. אני יודע שככה יהיה)אגב מה שכמובן שליחה ב-POST פותרת - בלי קשר לבעייה שבשרשור - זה - שאפשר לצרף body... (אני לא חושב שזה לא אפשרי, אגב, לצרף body לבקשת GET. אני חושב שזה נטו סוג של המלצה - לשרת - לא לפרשן כלל את ה-body של בקשות GET)
ובקיצור יהיה נחמד לשדרג את ה-API כך שהתוכן יעבור בגוף הבקשה. כמו המבנה הראוי לAPI תקני -
@chv לא ממש מבין מה זה גוף הבקשה ...
המגבלות שכתבת עליהם, לפחות לפי הבנתי, היו מגבלות של השפה איתה אתה משתמש ולא בעיות שקשורות למבנה הApi עצמו. -
@שמואל אני חושש שיש לנו כאן סוג של שיח חרשים..
אני יסביר פשוט:
כל מה שכתבתי בפוסט הארוך זה שלא הייתה שום בעיה מבחינתת הAPI אלא כל הבעיה הייתה בשליחה (כלומר אצלי, כן)
אתה הגבת לי על זה שאם שולחים בPOST יכול להיפתר הרבה דברים - כתבתי לך על זה שזה לא קשור (זה כלל לא קשור כשמדברים על הבעיות שהסברתי לעיל)כתבתי לך חוץ מזה - שהייתי מעדיף שהתקשורת מול ה-API לא תהיה URL'ית אלא שהתוכן של הבקשה יועבר על ידי המשתמש דרך ה-body. (כמקובל, ב-JSON וכו') מה ש-א' פותר הרבה דחקים, ב' מאפשר דינמיקה רחבה הרבה יותר של המידע ועיבודו הן על ידי השולח הן על ידי השרת של ימות.
הוספתי שכמובן - רק ב-POST זה יעבוד (כי בקשות GET לא יכולות להכיל body. כלומר יכולות להכיל אבל לא יתייחסו לזה כו')
@שמואל אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
לא ממש מבין מה זה גוף הבקשה ...
גוף הבקשה == body
-
@chv כדי לקודד שורה חדשה ב url כותבים %0A
-
@ערוץ-הסקרים אכן.
אני לא מדבר על צורה שאני מקודד לבד.. זה מקודד אוטומטית על ידי encodeURI של JS
