เมธอด HTTP SEARCH แบบใหม่
(httptoolkit.tech)-
แนะนำเมธอด SEARCH ที่ถูกเพิ่มเข้ามาเป็น Draft ใหม่ใน IETF
-
สำหรับการดึงข้อมูลที่ซับซ้อน การใช้เพียง GET/POST แบบเดิมนั้นไม่มีประสิทธิภาพ
SEARCH /customers HTTP/1.1
Host: example.com
Content-Type: application/sql
SELECT username, email
WHERE DATEDIFF(DAY, GETDATE(), signup_date) > 7
-
ในทางปฏิบัติไม่ได้หมายความว่าจะใช้คำสั่ง SQL เป็นมาตรฐานจริง ๆ แต่หมายถึงว่าสามารถใส่คอนเทนต์ลักษณะนี้เพื่อการค้นหาไว้ใน request body ได้
-
ทำให้ URL เดียวกันสามารถรองรับได้ทั้ง GET, POST และ SEARCH
-
สามารถระบุฟอร์แมตที่ใช้ในการค้นหาผ่านเฮดเดอร์ Accept-Search ได้ :
→ Accept-Search: application/sql, application/graphql
- อ้างอิงจากมาตรฐานเมธอด SEARCH ที่เคยมีใน WebDAV (rfc5323)
9 ความคิดเห็น
OData เป็นข้อกำหนดสำหรับการคิวรีในลักษณะนี้ที่ค่อนข้างคล้ายกันมากอยู่แล้ว แต่บอกว่าสามารถใช้
application/sqlและapplication/graphqlบน endpoint เดียวกันได้ด้วยนี่สิ.. นึกภาพไม่ค่อยออกเลยตัวการใช้งานเองน่าจะเป็นกรณีที่การยิง SQL ตรง ๆ มีปัญหา และเหมือนกับ elasticsearch ที่ในเชิงความหมายคือ
GETแต่ต้องการใส่ HTTP Body เพื่อใช้ในการค้นหาหรือดึงข้อมูลตรงช่วงต้นบทความที่บอกว่า "it was recently adopted as an IETF draft standard" นี่ คำว่า recently ที่พูดถึงหมายถึงปี 2015 ใช่ไหมครับ? ดราฟต์ที่ผมเห็นคือ https://tools.ietf.org/html/draft-snell-search-method-00 นี้ เลยสงสัยว่ามีการเปลี่ยนแปลงที่ใหม่กว่านี้หรือเปล่าครับ
เมธอด HTTP SEARCH ใหม่
คือ https://datatracker.ietf.org/doc/… ครับ
ดูเหมือนว่าเพิ่งอัปโหลดเมื่อ 2021-03-31 ไม่นานนี้เอง
ถ้าจะส่งข้อมูลไปใน body ก็คงต้องใช้ PUT หรือ POST
พวกนี้ใช้ cache ไม่ได้ ก็เลยอาจใช้สิ่งที่เรียกว่า SEARCH ได้เหมือนกัน
ยังไงก็ส่งเฉพาะตอนที่ accept เท่านั้นอยู่แล้ว
ทำให้นึกถึง GraphQL ในแง่ของการพยายามปรับปรุงความไม่สะดวกของ get และ post
พอเริ่มส่งคิวรีผ่าน request body ก็รู้สึกว่าไม่ช้าก็เร็วคงจะเกิดปัญหาอย่าง SQL Injection ได้เหมือนกันนะครับ (ถ้าเป็นเว็บที่ทำขึ้นมาแบบไม่ได้คิดอะไรมาก)
น่าจะเข้าใจได้ประมาณว่าเป็น GET ที่มี body อยู่ดี อย่างไรก็ตาม ยังไงก็ต้องทำ validation ให้กับ body อยู่แล้ว...
นั่นสินะ..