הבעיה

זו בעיה קלאסית של בקשת get עם פילטרים או יותר גרוע - עם גוף הודעה.
אז הפרקטיקה הייתה כזו:

1. או בקשת POST כשאילתא, למשל ב-ElasticSearch.
2. בקשת GET עם הרבה פילטרים.

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

1. אם משתמשים ב-url כדי לאגד פילטרים, אפשר בקלות להגיע לאורך גדול, יותר מ2000 או 8000 אפילו.
2. בלבול בין בקשת יצירה לבקשת שאילתא מאחר ומשתמשים ב-POST.
3. רוב השרתים לא מממשים קריאת גוף ב-GET.

הפתרון

הפתרון הוא שימוש במתודה חדשה בשם QUERY שמקבלת גוף.
ה-Headerים שמתמשים בהם הם:

• Content-Type - אותו דבר, איזה תוכן נקבל.
• Accept - מה השרת מוכן לקבל.
• Accept-Query - האדר חדש שאומר איזה פורמט של שאילתא זה יכול לקבל.

דוגמא

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json

select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
Response:

HTTP/1.1 200 OK
Content-Type: application/json

[
  { "surname": "Smith",
    "givenname": "John",
    "email": "smith@example.org" },
  { "surname": "Jones",
    "givenname": "Sally",
    "email": "sally.jones@example.com" },
  { "surname": "Dubois",
    "givenname": "Camille",
    "email": "camille.dubois@example.net" }
]

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

תודה על הקריאה!