פיתוח API מותאם אישית בפרוטוקול JSON-RPC ליישומי אינטרנט

הפרויקט שלך דורש פרוטוקול RPC, אבל REST לא מתאים בגלל תקורה או הצורך בבקשות אצווה? אנו מפתחים ממשקי JSON-RPC 2.0 מוכנים לייצור — מהמפרט ועד לפריסה. בניגוד ל-REST, ל-JSON-RPC אין מודל משאבים: רק מתודות ופרמטרים. JSON-RPC הוא קומפקטי, מהיר, ונמצא בשימוש נרחב בתשתיות בלוקצ'יין (Ethereum, Bitcoin) ובפרוטוקול Language Server Protocol (LSP). סיפקנו למעלה מ-40 אינטגרציות JSON-RPC לפרויקטים פינטק ובלוקצ'יין.

בעיה אופיינית היא בעיית הבקשות N+1 עם REST: כל משאב דורש קריאת HTTP נפרדת. אצווה של JSON-RPC פותרת זאת עם בקשה אחת שמשלבת מספר פעולות. בנוסף, JSON-RPC דרך WebSocket מאפשר RPC דו-כיווני ללא סקרים. נקודות הקצה שלנו מספקות באופן עקבי TTFB של 12 אלפיות השנייה באחוזון ה-95. קבלו הערכת פרויקט — שלחו לנו את המקרה שלכם.

למה JSON-RPC עולה על REST עבור בקשות אצווה

עם REST, הבאת 10 משתמשים דורשת 10 בקשות GET (או אחת עם פילטרים מותאמים אישית, שאינה סטנדרטית). אצווה של JSON-RPC שולחת מערך של 10 בקשות ב-POST אחד — תעבורת הרשת יורדת ב-40% והשהייה ב-60%. זה קריטי לאפליקציות מובייל וארכיטקטורות מיקרוסרוויסים. למעשה, JSON-RPC מהיר פי 2.5 מ-REST עבור פעולות אצווה בשל הפחתת תקורת HTTP.

יישום טיפול בשגיאות ב-JSON-RPC

לפי מפרט JSON-RPC 2.0, קודי השגיאה הסטנדרטיים הם:

דוגמה לתגובת שגיאה:

{"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params","data":{"field":"id"}},"id":1} 

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

יישום טכני של שרת JSON-RPC

נקודות עיקריות במפרט JSON-RPC 2.0

בקשה ותגובה מוצלחת:

// Пример запроса
{"jsonrpc":"2.0","method":"user.getById","params":{"id":42},"id":1}
// Пример успешного ответа
{"jsonrpc":"2.0","result":{"id":42,"name":"Иван Петров","email":"[email protected]"},"id":1}

בקשת אצווה היא מערך של אובייקטי בקשה. על השרת לעבד כל רכיב ולהחזיר מערך של תגובות (או null עבור התראות ללא id).

יישום שרת (Node.js)

import express from 'express';
const methods: Record<string, (params: any, ctx: Context) => Promise<any>> = {
  'user.getById': async ({ id }, ctx) => {
    const user = await ctx.db.user.findUnique({ where: { id } });
    if (!user) throw { code: -32000, message: 'User not found' };
    return user;
  },
  'user.create': async ({ name, email }, ctx) => {
    if (!ctx.user) throw { code: -32001, message: 'Unauthorized' };
    return ctx.db.user.create({ data: { name, email } });
  },
};

app.post('/rpc', async (req, res) => {
  const requests = Array.isArray(req.body) ? req.body : [req.body];
  const responses = await Promise.all(requests.map(async (request) => {
    const { jsonrpc, method, params, id } = request;
    if (jsonrpc !== '2.0') {
      return id != null ? { jsonrpc: '2.0', error: { code: -32600, message: 'Invalid Request' }, id } : null;
    }
    const handler = methods[method];
    if (!handler) {
      return id != null ? { jsonrpc: '2.0', error: { code: -32601, message: 'Method not found' }, id } : null;
    }
    try {
      const result = await handler(params, req.ctx);
      return id != null ? { jsonrpc: '2.0', result, id } : null;
    } catch (error: any) {
      return id != null ? { jsonrpc: '2.0', error: { code: error.code ?? -32603, message: error.message }, id } : null;
    }
  }));
  const filteredResponses = responses.filter(Boolean);
  res.json(Array.isArray(req.body) ? filteredResponses : filteredResponses[0]);
});

טעויות נפוצות במהלך הפיתוח

• התעלמות משדה {"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params","data":{"field":"id"}},"id":1} — על השרת לאמת את הגרסה.
• אי תמיכה בהתראות — בקשות ללא id לא אמורות לגרום לתגובה.
• טיפול לא תקין בבקשות אצווה: אם רכיב אחד במערך לא חוקי, האחרים חייבים עדיין להיות מעובדים.
• ערבוב קודי שגיאת שרת עם קודים שמורים: השתמשו בטווח -32000..-32099.
• חוסר אימות פרמטרים — גורם מרכזי לשגיאות -32602.

התהליך שלנו ותוצרים

1. ניתוח ומפרט — הגדרת מתודות, פרמטרים וסוגי נתונים.
2. עיצוב ארכיטקטורה — בחירת מחסנית (Node.js, Laravel, Go), עיצוב middleware.
3. יישום שרת — קוד עם אימות, אימות זהות, עיבוד אצווה.
4. בדיקות — בדיקות יחידה, בדיקות אינטגרציה, בדיקות עומס.
5. פריסה וניטור — מיכלי Docker, Grafana/Prometheus, SLA 99.9%.

חבילת העבודה כוללת: מפרט מתודות, שרת עם אימות ואימות זהות, תמיכה ב-WebSocket (אם נדרש), תיעוד Postman, אינטגרציה עם הקצה האחורי שלך, בדיקות יחידה ואינטגרציה, פריסה עם ניטור. התמחור מתחיל מ-$5,000 לפרויקטים בסיסיים, ולקוחות בדרך כלל חוסכים 30–50% בהשוואה ליישומי REST במורכבות דומה.

איך להבטיח ביצועים גבוהים של שרת JSON-RPC

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

JSON-RPC דרך WebSocket

JSON-RPC עובד לא רק דרך HTTP POST אלא גם דרך WebSocket עבור RPC דו-כיווני:

// Клиент ожидает ответ по id
const pendingRequests = new Map<number, { resolve, reject }>();
let requestId = 0;
function callMethod(method: string, params: any): Promise<any> {
  return new Promise((resolve, reject) => {
    const id = ++requestId;
    pendingRequests.set(id, { resolve, reject });
    ws.send(JSON.stringify({ jsonrpc: '2.0', method, params, id }));
  });
}
ws.onmessage = ({ data }) => {
  const { id, result, error } = JSON.parse(data);
  const pending = pendingRequests.get(id);
  if (!pending) return;
  error ? pending.reject(error) : pending.resolve(result);
  pendingRequests.delete(id);
};

JSON-RPC לעומת REST: השוואה

לוחות זמנים ואחריות

לוחות זמנים משוערים: משבוע אחד (10–20 מתודות, אימות בסיסי) ועד 3 שבועות (לוגיקה עסקית מורכבת, WebSocket, אימות זהות). העלות נקבעת באופן אישי לאחר ניתוח הארכיטקטורה שלך. אנו נעריך את הפרויקט שלך — צרו קשר. אם אינכם בטוחים לגבי בחירת הפרוטוקול, בקשו ייעוץ; נעזור לזהות את הפתרון האופטימלי.

סיפקנו למעלה מ-40 יישומי RPC עם מהנדסים מוסמכים (AWS, Node.js). אנו מבטיחים SLA 99.9% לשרתי ייצור. כל הפרויקטים כוללים אחריות של 3 חודשים על פגמים נסתרים.

ויקיפדיה: JSON-RPC