@שמואל זה פשוט מאוד
אם אתה צריך עזרה אני יכול בשמחה
אגב למה באמת לא אפשרי לקבל ישירות לפרטי?
@שמואל זה פשוט מאוד
אם אתה צריך עזרה אני יכול בשמחה
אגב למה באמת לא אפשרי לקבל ישירות לפרטי?
@ערוץ-הסקרים אכן.
אני לא מדבר על צורה שאני מקודד לבד.. זה מקודד אוטומטית על ידי encodeURI של JS
@שמואל אני חושש שיש לנו כאן סוג של שיח חרשים..
אני יסביר פשוט:
כל מה שכתבתי בפוסט הארוך זה שלא הייתה שום בעיה מבחינתת הAPI אלא כל הבעיה הייתה בשליחה (כלומר אצלי, כן)
אתה הגבת לי על זה שאם שולחים בPOST יכול להיפתר הרבה דברים - כתבתי לך על זה שזה לא קשור (זה כלל לא קשור כשמדברים על הבעיות שהסברתי לעיל)
כתבתי לך חוץ מזה - שהייתי מעדיף שהתקשורת מול ה-API לא תהיה URL'ית אלא שהתוכן של הבקשה יועבר על ידי המשתמש דרך ה-body. (כמקובל, ב-JSON וכו') מה ש-א' פותר הרבה דחקים, ב' מאפשר דינמיקה רחבה הרבה יותר של המידע ועיבודו הן על ידי השולח הן על ידי השרת של ימות.
הוספתי שכמובן - רק ב-POST זה יעבוד (כי בקשות GET לא יכולות להכיל body. כלומר יכולות להכיל אבל לא יתייחסו לזה כו')
@שמואל אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
לא ממש מבין מה זה גוף הבקשה ...
גוף הבקשה == body
@שמואל אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
@chv שליחה בPOST פותרת את רוב הבעיות של ההגבלות של URL.
זה לא כ"כ קשור
זה לא יפתור, לדוגמא, את הבעיה שהייתה לי. (אני אפילו לא בודק. אני יודע שככה יהיה)
אגב מה שכמובן שליחה ב-POST פותרת - בלי קשר לבעייה שבשרשור - זה - שאפשר לצרף body... (אני לא חושב שזה לא אפשרי, אגב, לצרף body לבקשת GET. אני חושב שזה נטו סוג של המלצה - לשרת - לא לפרשן כלל את ה-body של בקשות GET)
ובקיצור יהיה נחמד לשדרג את ה-API כך שהתוכן יעבור בגוף הבקשה. כמו המבנה הראוי לAPI תקני
@jack אמר בקומבינה להעלאת משרת פודקאסט לימות המשיח באופן אוטומטי?:
יש לך ניסיון למשל עם ec2 של אמזון?
יקר יחסית, כבר עדיף גוגל קלאוד
לפני שאתה בודק חברות שרתים, תחליט איך אתה בונה את האפליקציה שתרוץ (באיזה שפה, למשל) יש הרבה דברים שתוכל להריץ חינם לגמרי ואפילו אם תשקיע מחשבה תוכל להוציא את זה לפועל על גבי כלי CI כגון גיטהב..
ומה לגבי מערכת טלפונית של ימות המשיח? יש מצב לעשות קומבינה דומה כדי להעלות לקו תוכן חדש כל כמה שעות באופן אוטומטי?
שוב - זה לא קשור לימות המשיח (לכאורה, מכיר אותם רק מלפני כמה ימים אבל ההיגיון אומר ששירות כזה גם אם קיים יעלה לך סתם כסף בזמן ש=)זה דבר שצריך להתבצע בשירות חיצוני - תוכנה שתכתוב וכדו' - שתעלה את הקובץ למערכת (זה כן יבוצע דרך ה-API של ימות, ובחינם..)
@שמואל
בסופו של דבר.. ואחרי כמה שעות ששברתי את הראש.. בדקתי מכיוון אחר את העניין ומה שיצא לי זה שהבאג לא אצל המפרסר של ימות אלא זה מגיע אליו לא בצורה הנכונה
אני מסביר בפירוט. למעוניינים במידע.
אמנם אני לא יכול להוריד פה מידע טכני ממש כי אני לא מבין באמת או יודע לעומק: אבל מה שיצא יצא:
כידוע אחד התווים שמייצגים שורה חדשה זה 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 מה שמחייב אותנו להרבה הגבלות של תווים (לא שהם מוגבלים, פשוט צריך לדעת איך לנווט כדי לשלוח אותם בבקשה)
וואי איזה ארוך
תודה לעוזרים תודה @שמואל
@שמואל אוה! הנה תשובה
בנוגע לדבריך >
תעשה לכל הטקסט urlencoder כולל לירידת שורה, אני לא חושב שיש הגבלה בכלל על תווים.
כמובן שעשיתי.. אני לא בור לגמרי (חבל שלא ציינתי את זה בשאלה)
מערכת סמסים שהיא רק לסמסים ניתנת מול שירות לקוחות, והיא מערכת נפרדת לחלוטין. אם אתה חושב שאתה צריך את זה תוכל לפנות לשירות לקוחות.
זהו שממה שכתוב כאן הבנתי שאפשרי ללא צורך בהתאמה מיוחדת, פשוט להשתמש בAPI לשלוח סמס
בהחלט, הקובץ לא ממש מעודכן, יש לך כאן תיעוד על כמעט כל האפשרויות שלא מתועדות בקובץ.
זו התשובה הרצויה.. אכן יש כאן הרבה יותר פירוט. ניכרת השקעה של מי שכתב שם את התיעוד (לא חבל להניח את התיעוד ככה באמצע שום מקום? אפשר לכתוב אותו בצורה יותר מעוצבת, יותר בהירה)
אם כי הקטע הרצוי הוא בדיוק ריק - https://f2.freeivr.co.il/post/32044
בכל אופן תודה
@אהרן-שובקס אמר בבקשת תיעוד על מבנה ה-API של שליחת סמסים:
הAPI של האתר sms של ימות
אשמח מאוד לקישור אם יש לך!!
אגב בנוגע לתיעוד על הפונקציה הזו שהובאה למעלה (runCampaign
) הביאו לי קובץ של תיעוד כללי של ימות - והקטע שמתאר את runCampaign
לא מכיל כלל שום אזכור בנוגע להרצת קמפיין ללא טמפלט (אין גם שום אזכור ל-withSMS
)
אני משער שזו פונקציה חדשה שנכתבה אחרי שכתבו את התיעוד.. אבל חבל שאין מקום מעודכן
שלום לכולם..
לא יצא לי מעולם להתעסק עם שום פיצ'ר כזה או אחר של ימות המשיח. היום התעסקתי עם שליחת SMS דרך API וראיתי את זה
אני מעתיק משם דוגמא של ה-API >
https://www.call2all.co.il/ym/api/RunCampaign?token=091234567:1234&withSMS=1&phones={"0533123456":"פנייה מספר 159 למוקד טופלה"}
אם המספר לא כשר הוא אמור לשלוח לו סמס.
אוקיי.. בדקתי את זה וזה עובד מעולה (ואגב זול בטירוף, יחסית לחברות אחרות שהרבה יותר מסובכות)
הבעיות שלי הן -
ובקיצור אם מישהו יודע על מקור מידע נורמלי ומסודר שמרכז את המידע והמתודלוגיה של ה-API הזה. אשמח מאוד!!!
אני לא יודע על המבינים כאן וכו' אז אם מישהו שרואה את זה יודע את מי לתייג - אז בכלל