תחומים - פורום חרדי מקצועי

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

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

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

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

לעומת זאת בnodejs למשל,
א. כל הבקשות רצות על אותו קונטקסט משותף, אתה יכול לשמור את מספר המבקרים במשתנה, ללא שום SQL.
ב. הכל טריד אחד, כל בקשה מתבקשת לחכות עד שהשרת משועמם (!) ואז הוא עונה לה.
זה גורם לכך ששרת בעל כח X יכול לשרת פי מאה בנוד מאשר בPHP. כמובן שזה תלוי עד כמה ארכיטקט התכונה התחשב באופי השפה, אבל בתצורה שלך אז ייתכן שמדובר בפי אלף.

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

יש גם את ASP CORE שמשלב בין שתי הדרכים: כל בקשה היא טריד נפרד אבל באותו פרוסס וממילא מצד אחד יש תקורה קטנה של יצירת התהליכים אבל מאידך יש את מעלת הmulti-treading.
אני, אופיינית, תומך בדרך זו

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

ההמלצה שלי היא ASP.NET MVC. לא בגלל הרעיון עצמו, אלא
א. פשוט כל ההיבטים המודרניים של תעשיית התוכנה הוטמעו שם די טוב.
ב. הASP.NET הרגיל עובד עם WebForms ובן לוייתו ViewState שלדעתי זה טכנולוגיה נוראה. עדיף PHP או כל דבר אחר מזה.

נ.ב. הייתי ממליץ על ASP.NET MVC CORE, שזה גלגול מודרני יותר (בהרבה דברים), וכבונוס הוא חוצה פלטפורמות ורץ על כל מערכת.

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

לעומת זאת, איך עובד MVC בASP.NET:
קודם כל MVC זה תבנית עיצוב של תוכנה שנמצאת במגוון שפות וטכנולוגיות. הרעיון שלה הוא שהמשתמש עובד מול תצוגה (V), התצוגה נוצרת ע"י הבקר (C), ואותו הבקר הוא גם זה שמגיב על אירועי/בקשות המשתמש דרך התצוגה (ביישום אינטרנט המונח הנכון זה בקשות). הבקר עצמו ממונה רק על התקשורת, כשהמידע הגולמי מועבר/מתקבל על ידו מ/אל המודל (M).
זה יפה לתיאוריה, למעשה יש חופש בתוך הכללים האלה.
בASP.NET הMVC נבנה עם הרבה השראה מRuby on Rails, שכוללת עקרונות שונים כמו CoC - Convention Over Configuration, שזה אומר בעברית "מוסכמות על פני הגדרות" - ההשלכה המעשית: כל פרט שניתן להניח מה תהיה ההגדרה שלו, זו התנהגותו ללא כתיבת הגדרה זו בפירוש. הכלל הזה ממש מכסה את כל מערכת הMVC בASP.NET.
עקרונות הליבה של יישום ASP.NET MVC:

1. ניתוב - Routing.
   ביישום אינטרנט מסורתי שורש הURL בעצם מפנה לשורש תייקת האתר, והנתיב מכאן ואילך הוא ביחס לשמה תיקיה בתוך תקיה וכו' עד לקובץ המתאים, למשל: http://example.com/directory-a/directory-b/file.php
   ביישום MVC הניתוב הוא מופשט ובלי קשר למבנה תיקיית האתר. בעצם ישנו "מטפל" אחד בכל הנתיבים, שלפי הנתיב מנתב למתודה של קונטרולר. בברירת מחדל (מוסכמה) האיבר הראשון אחרי שורש האתר מצביע על שם הקונטרולר, והשני על מתודה שבו, אלא שאחריהם יכולים להיות מנותבים לפרמטרים למתודה.
2. בקרים - Controllers
   יכול להיות כמה בקרים שרוצים, ברך כלל הם תחת תיקיה בשם Controllers. בכל Controller יש כמה מתודות, כל אחת בדרך כלל אחראית לייצר תצוגה.
   (יש גמישות מלאה איזה מתודות לשים באיזה בקר, בעצם זה נטו עניין של טעם אישי וסדר כמו תיקות וקבצים).
3. תצוגות - Views
   הרעיון של תצוגה בMVC זה פיסת פרוצדורה שלא עושה שום דבר שלא נוגע לתצוגה, והיא מתקשרת אך ורק עם הController.
   בASP.NET נעשה שימוש במנוע תצוגה נח וקל מאוד בשם RAZOR הוא הטוב ביותר שקיים לדעתי.
   התצוגות בדרך כלל מקובצות בתיקיות כשכל קבוצת תצוגות ששייכת לבקר מסויים נמצאות תחת תיקיה כשם הבקר, שהיא תחת תיקיה ראשית בשם Views.
4. מודלים
   זה "סתם קוד", שעל פי הכללים עדיך לעשות בו את הלוגיקה והעבודה עם המסד נתונים וכו' מאשר בבקר. כמובן שאין על זה קנסות מהמשטרה ואפשר להתגמש אבל זה הדרך לפי הספר.

בקשר לשפה, יש לך את VB בשניהם, כלומר VB.NET, יש חלקים מתקדמים בשפה כמו Attribute שהופכים בMVC להיות בשימוש תכוף מאשר בטכנולוגיות אחרות, אבל אלו לא דברים שמחייבים הבנה מעמיקה.

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

אני מעודד לקפוץ למים גם תוכל לקבל פה עזרה ובפרט בפורום האקסקלוסיבי.

אפשר לראות את המצב הנוכחי בשורה למטה

@avi-rz הלואי, הבעיה שלא כולם יכולים להיות מנהלים. בטח שאם זה הולך לך, לך על זה בכל הכח.
באריכות: אתה צודק לגמרי שמנהל לא צריך להיות מתכנת X10 ובמידה מסויימת אפילו לא צריך לדעת לכתוב קוד. בפרט בדרך ניהול מונחה משימות (להבדיל ממיקרו-ניהול), ובעצם אנחנו מדברים בכל הנושא רק על מנהלים מהסוג הזה.
בעצם מנהל הוא זוג של רכז, שככל שהוא מבין יותר את התחום יש לו ייתרון אבל הוא לא צריך בכלל את הייתרון הזה כדרישת סף.
ואכן מקצוע הניהול מייתר את כל המקצועות האחרים. תמיד להיות מנהל מצליח ורווחי יותר מלהיות מומחה בכל תחום. מנהל בית חולים הוא הרבה פעמים רופא ממוצע ומטה אם בכלל (למרות תואר הפרופסור שלו), וביל גייטס בטח איבד את כישורי הפיתוח של מאוד מהר במהלך הקריירה. למרות המסורת בארץ ששרי ביטחון למשל יהיו עם ניסיון צבאי (אולי בשביל ייתרון של המיקרו-ניהול או הבנה מעמיקה יותר של ה"איך"), ברוב המקרים האחרים אין את זה בכלל.
מנהל גם מרויח הרבה יותר ממתכנת ובעצם אין גבול לרווחים שהוא יכול לקבל (כיזם/עצמאי/או מנהל חברה עשירה), וזה שיקול בהשתדלות אם שני המקרים מתאימים במידה שווה לאדם.
אלא שמנהל מסוג זה גם צריך כישורים. הוא צריך דבר ראשון להצליח לפעול מכח הסיפוק הזה, בלי הסיפוק של החכמה או היצירה האישית (בפרט כשהעובדים שלך מוכשרים ממך אפילו בליטוש הרעיון או שינוי לחלוטין), שנית הוא צריך להיות בעל יכולת של "התנתקות" מה"איך" במידה רבה. למתכנתים (במידה מובהקת) שאני מכיר אין את שני הדברים, וממילא זה לא השתדלות וחלקם אפילו לא אפשרי.

@eido כתב בנתקלתי אתמול בבאג חמוד:

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

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

אתה עושה טבלה נפרדת, ששמה יש מה הוא שמע, נניח נקרא לה ModhaToPhone, יש בה שלוש עמודות: ModhaId, Phone, At שזה מזהה מודעה, מזהה מאזין - מספר טלפון ותאריך.
בשליפת הסינון אתה מחבר בין הטבלה של הדירות (מודעות) לטבלת הדירה_מאזין עם LEFT JOIN עם התניה שדירה_מאזין ריק, ככה:

SELECT * FROM Modaot
LEFT JOIN ModhaToPhone ON ModhaToPhone.ModhaId = Modaot.Id AND ModhaToPhone.Phone = '050xxxx'
WHERE ModhaToPhone.ModhaId  IS NULL

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

נוסח שונה לשליפה:

SELECT * FROM Modaot
WHERE NOT EXISTS(
    SELECT 1 FROM ModhaToPhone WHERE ModhaToPhone.ModhaId = Modaot.Id AND ModhaToPhone.Phone = '050xxxx'
)

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

אדגיש קודם שבמקרה הזה התשובות שאני אומר הם לא דעתי האישית או נטיית דעה/לב, אלא עקרונות מאוד חד משמעיים שמקובלים בכל מערכת נורמלית.
א. טבלת users אחת. role בטבלה או בטבלה נפרדת, אני מעדיף נפרדת עם אפשרות של יותר מrole אחד למשתמש.
ב. הסתרת נקודת קצה לא מועילה כלום באבטחה. זה נכון שיהיה קשה לתוקף לדעת, אבל זה לא נחשב שעשית אפילו מילמטר מבחינת אבטחה.
אם האבטחה שלך היא ללא פגם, לא היית מרגיש צורך בסניף המסכן הזה, ולהיפך, אם יש לך קצת הישענות על הסתרת נקודת הקצה של המנהל, יש פגם באבטחה שלך. זה צריך להיות מאה אחוז גם אם כל העולם יודע.
(יש אמנם עיקרון של ערפול כאבטחה (Security through obscurity ראה פה), אבל הוא עיקרון מצומצם שאף פעם לא צריך לעמוד בשיקולי ארכיטקטורה, ובשום אופן לא להיות אפילו סניף לאבטחה. זה אולי אולי תוספת להוסיף למהדרים אחרי שהמערכת 100 אחוז, אני בעד לוותר על ההידור שמביא לידי קולות).
אם אתה רוצה להתייעץ על איך ניתן לפרוץ למערכת שלך והאם האבטחה שלך מספיקה, זה נושא מעולה לדיון.

שאלה דומה בסטאק:
https://stackoverflow.com/questions/27972271/sequelize-dont-return-password
אני חושב שזו דוגמה טובה לבלגן ה"איך" ששורר בnodejs.
בעוד בC# יש עומס מרגיז של שיטות וכללי עצוב, בנוד חסר מאוד כאלו.
אגב הרבה לא שמים לב למשהו שיותר מסוכן - הכיוון ההפוך של קבלה מלקוח,
כשמקבלים מהלקוח אובייקט יש סכנה יותר הפוכה שנקראת Mass Assignment או Overposting שזה מתי שהקוד בצד שרת מקבל אובייקט ולמשל מעדכן על פיו את מסד הנתונים בדינמיות, אך בעוד לקליינט מותר לערוך רק את כתובותו האישית, הוא מוסיף שדות שהוא בכלל לא אמור להיות יכול לשנות (את שמם הוא מנחש או יודע דרך הבעיה של @yossiz).
בexpress למשל, מצוי שרואים קוד בסגנון הזה:

app.post('/update', async (req, res) => {
   if(req.body.id != req.seesion.user.id) return res.status(403);
   await connection.query('UPDATE users SET ? WHERE id = ?',  [req.body, req.body.id]);
   ...
});

הקוד הזה שהוא ממש קסום מבחינת פשטותו, הוא פרצת אבטחה בה משתמש יכול לשנות כל שדה, כולל את הID (ל1 למשל ואז הוא בטוח מנהל...)....
ראיתי מלא קוד דומה בפרודקשיין! יש פה טענה קצת על ספריית mysql שעשתה חיים מידי יפים בלי שום התרעה או אזהרה בתיעוד, אבל בnosql המצב הרבה יותר חמור.
בנוסף, בגלל שאין טיפוסיות קשוחה בJS המשתמש יכול לנצל את זה ולשלוח טיפוס שמצד אחד ייתמך במסד נתונים כדי שלא תהיה שגיאה בהכנסה או העדכון, אבל יהיו לכך השלכות לא טובות לגבי הלוגיקה בהמשך. אפילו מחלקה בנויה יפה בtypeScript לא תעזור פה שהרי בזמן ריצה הוא JS והוא מסכים הכל.
יש ספריות לזה, כמו express-validator אבל מי משתמש בה ביחס לכלל? זה אחת הבעיות של הטכנולוגיות המדליקות והחופשיות, אין שמה נורמות בסיסיות מרוב שרוצים לתת את ההגה למפתח.
מאמרים על Mass Assignment בנוד:
https://snyk.io/blog/avoiding-mass-assignment-node-js/
https://knowledge-base.secureflag.com/vulnerabilities/inadequate_input_validation/mass_assignment_nodejs.html

צרי להוסיף "או שווה למחרוזת ריקה".
הפכתי לך את התנאי כי לדעתי זה יותר קריא:

IIf([שם פרטי] IS NULL OR [שם פרטי] = "", "", "שם פרטי:" & Chr(13) & [שם פרטי] & Chr(13))

יש לציין שChr(13) נצרך לקפיצת שורה, אם אתה רוצה סתם רווח כתוב ככה:

IIf([שם פרטי] IS NULL OR [שם פרטי] = "", "", "שם פרטי: " & [שם פרטי])

@יהודי-טוב כתב בהשמעת audio בתגית audio כשהמקור הוא קובץ להורדה (ימות המשיח):

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

זה נראה פרשנות שלך לבעיה.
היה עוזר לראות שגיאות קונסול או רשת.
בקוד שלך חסר מרכאות כפולות מסביב ל{src}.

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

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

בשביל לזהות מה ואיך הדפדפן שולח לשרת בעת ובפרט בסיום המילוי,
עליך לפתוח את כלי המפתחים, לעבור ללשונית Network - רשת, ושמה לנקות את הבקשות הקודמות על ידי לחיצה על סמל האין כניסה, ולוודא שהסמל העגול שלידו מסומן באדום - כלומר מתעד פעולות רשת.
כעת תמלא את הטופס, ושים לב לבקשות. יש בקשות לא רלוונטיות, כמו רשימת ערים או תמונת כפתור שעלולים להיות תוך כדי, אבל יש בקשות יותר חשובות כמו בקשת טוקן וכדומה שעלולה להתברר כמעניינת.
הרגע הכי חשוב זה רגע שליחת הטופס, שלכאורה רק הוא נצרך. צריך לוודא לפני הלחיצה דבר ראשון שהאפשרות Preverse log מוסמנת שלא יעלם תיועד בעת ניווט מחדש לדף אישור/תודה באם ישנו. צריך לשים לב גם מה השורה האחרונה, כדי שיהיה קל לראות איזה פעילות יצרה הלחיצה.
כעת אתה לוחץ, בד"כ זה יוצר שורה שמייצגת בקשת POST, ובליחצה על השורה בכרטסת Payload (לא יודע איך זה בעברית) יש את המידע שהדפדפן שולח לשרת. בכרטסת Response יופיע תשובת השרת. נקודת המוצא היא שזו השורה היחידה הנדרשת, אז עליך לנסות לחקות אותה עם כלים תכנותיים, כמו fetch בקונסול של הדפדפן או כל דרך אחרת. אם זה עובד מוטב, אם לא צריך לבדוק לאט לאט את הpayload ואת כותרות הבקשה, האם יש בהם מידע שמסגיר עקבות קודמים כמו עוגיות וכדומה, ולפתור בעיה בעיה עד שהכל עובד.
מעקב הכונה שהשרת עלול לדחות בקשות שלא עולות בקנה אחד עם בקשות קודמות, ולעיתים יש אפילו תחכום לוודא שהבקשות היו בסדר/קצב/אופן אנושי, כשזה מגיע לבדיקות ברמה חריפה קשה לדעת את כל זה ולכן עוברים לאוטומציה של דפדפן שאז אתה עם הקוד פשוט מפעיל ברקע דפדפן שמשתדל לעשות כל מה שדפדפן רגיל עושה כמו אירוע מעבר עכבר וכולי.

@אחד-וחצי כתב באתר קניות עם פונקציות:

יש מישהו שמסוגל? מה המחיר לדבר כזה.

בשביל לתת מחיר (אפילו כיוון) צריך לפרט את השורה וחצי שכתבת לאפיון של כמה מאות מילים לפחות.

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

אינטרנט, HTML, זה מחייב הבנה בסיסית בארכיטקטורת שרת לקוח.
שרת לקוח זה אומר שישנם שתי תכונות בעצם.
אחת רצה בלקוח בדפדפן והיא בעצם הקוד שמופעל על ידי דף האינטרנט, ואחת רצה במחשב כל שהוא (רחוק קרוב או אותו אחד בו הדפדפן פתוח, אז בד"כ הכתובת היא localhost/127.0.0.1).

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

דוגמה לא', אי אפשר בתוכנת שבדפדפן להורות על כיבוי המסך, על מזעור החלון וכדומה.
דוגמה לב', אי אפשר בתוכנה שבדפדפן להורות על השמעת אודיו במחשב אחר.

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

SQL SERVER זו תוכנה שנמצאת במחשב כל שהוא. התקשורת איתה מתבצעת (על פי רוב מוחלט) בפרוטוקול TCP, שהוא גם הפרוטקול אב של הHTTP.
נניח שהSQL-SERVER רץ במחשב X.
גם אם נריץ באותו המחשב דף אינטרנט, אין ביכולתו לשוחח עם הSQL SERVER מסיבה א'. הדפדפן לא מספק בכלל פקודה עבור התכונה בדפדפן שעימה הוא יוכל לתקשר בTCP.

טוב בשביל מה כל האריכות הזו? הרי אתה ידעת זאת לכאורה מצויין, ואתה שואל על BLAZOR SERVER שזה תכונה עצמאית, נפרדת, שלא רצה במסגרת הדפדפן בכלל, אלא עצמאית לחלוטין. הדפדפן סה"כ אומר לה (על ידי קוד יפה שהם הכינו מראש) על מה לחצו ומה השתנה, ואז היא מעבדת את התוצאה ושולחת HTML רלוונטי מתאים שוב.
אין הכי נמי, האריכות מיותרת אבל זה רק בשביל חידוד העניין והבהרתו.
בהודעה הבאה אענה לך בל"נ על השאלה.

@OdedDvir כתב בבנייה נכונה של API לעריכת ישות עם כמה ישויות קשורים:

פוק חזי וכו' ואתה מכיר את הדרך המקובלת של RESTful API

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

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

@segev_gr באופן כללי הכי חשוב זה מה השגיאה, אבל גם יעזור אם תצרף קוד קצר.
אבל במקרה הזה קל לנסות לבד, והרצתי את זה לבד.
ראשית כל שמתי את זה בדפדפן והסתכלתי מה קורה בכלי המפתחים ברשת (F12), והכל היה נראה טוב. הרצתי את השאילתה בC# ואכן הייתה תשובה של 301 עם מסך קאפצ'ה.
התחלתי להוסיף כותרות של דפדפן קלאסיות, ומה שראיתי שמשנה זה הכותרת Accept-Language, ברגע ששמתי את זה זה עבד.

@ליה מעבר על מאפייני אובייקט נעשה בעזרת Object.keys שנותן את שמות המפתחות, או לולאת for .. in שנותנת גם את שמות המפתחות, או מתודת Object.entries שמחזירה אוסף של זוגות מפתח-ערך, ועוד.
לשםמעבר עמוק, כלומר שבכל מפתח בודקים את הערך ואם הוא אובייקט יורדים גם לרמה שלו, אפשר להשתמש ברקורסיה. הנה דוגמה:

     function iterateDeep(obj)
     { 
       if (Object(obj) === obj)
         for (const [k, v] of Object.entries(obj))
           iterateDeep(v);
       else
         console.log("item: " + obj);
     }

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

  if (Object(obj) === obj) {
    for (const [k, v] of Object.entries(obj))
      if(!v.passLoop){
         iterateDeep(v, [...keys, k]); 
         v.passLoop = true;
      }
  } else
     console.log("item: " + obj);
    

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

function iterateDeep(obj, keys = [])
{ 
  if (Object(obj) === obj) {
    for (const [k, v] of Object.entries(obj))
      if(!v.passLoop){
         iterateDeep(v, [...keys, k]); 
         v.passLoop = true;
      }
  } else
    console.log(`${keys.join('.')}: ${obj}`);
}

@clickone הדרך שהבאת ממש אלגנטית! במקום להתחיל לכתוב את הקוד של המרת 64 לטקסט.
החבילה הזו דפוקה שהיא לא עושה את זה, כי זה ממש התפקיד שלה.
הקידוד לא חייב להיות ככה, הוא מוגדר בשורה הזו:

N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:;=

שנמצאת מעל כל איש קשר.
QUOTED-PRINTABLE זה שם הקידוד.