26 คะแนน โดย GN⁺ 2024-05-05 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • JSON Path เป็นภาษาคิวรีที่ใช้ดึงข้อมูลจากเอกสาร JSON ได้
  • เนื่องจาก OpenAPI เป็นเอกสาร JSON หรือ YAML จึงสามารถใช้ JSON Path ทำงานได้หลายอย่างกับ OpenAPI
    • แพตช์เนื้อหาเพิ่มเติม ตัวอย่างโค้ด ฯลฯ ลงในเอกสารด้วย OpenAPI Overlay
    • ใช้ใน Spectral เพื่อเขียนกฎขั้นสูงได้
    • ใช้ใน AWS Step Functions ได้เช่นกัน
  • วิธีการทำงานของ JSON Path
    • ใช้สำรวจ กรอง และดึงเฉพาะส่วนที่ต้องการจากโครงสร้างข้อมูล JSON
    • มีไวยากรณ์คล้าย XPath (ที่ใช้กับ XML)
    • ตัวอย่างไวยากรณ์: $.store.book[?@.price < 10].title
  • การใช้งานใน OpenAPI
    • ใช้คำสั่ง jpp เพื่อคิวรีเอกสาร OpenAPI และดึงเฉพาะส่วนที่ต้องการได้
    • ใช้ Overlay เพื่อแก้ไขเอกสาร OpenAPI หรือเพิ่มข้อมูล
      • อัปเดตคำอธิบาย เพิ่มข้อมูลติดต่อ เป็นต้น
      • ลบเซิร์ฟเวอร์ development/staging ออกจากรายการเซิร์ฟเวอร์ และคงไว้เฉพาะ production
      • เพิ่มข้อมูลเซิร์ฟเวอร์ sandbox ใหม่ เป็นต้น
  • เรียนรู้ JSON Path เพิ่มเติม
    • ได้รับการกำหนดเป็นมาตรฐานโดย IETF ในปี 2024 (RFC 9535)
    • ก่อนหน้านี้มีหลายรูปแบบย่อย แต่แนวโน้มกำลังมุ่งสู่การรวมเป็นมาตรฐานเดียว
    • ควรยึดตามไวยากรณ์ของ RFC 9535

ความเห็นของ GN⁺

  • JSON Path ถูกใช้งานมากขึ้นเรื่อย ๆ จึงเป็นทักษะที่ควรรู้ไว้ โดยเฉพาะสำหรับนักพัฒนาหรือนักเขียนสายเทคนิคที่ทำงานกับ OpenAPI ซึ่งมีแนวโน้มว่าจะกลายเป็นทักษะจำเป็น
  • แม้ไวยากรณ์ของ JSON Path จะยังไม่เป็นเอกภาพทั้งหมดและอาจทำให้สับสนอยู่บ้าง แต่การยึด RFC 9535 เป็นหลักน่าจะเหมาะสมที่สุด และคาดว่าเครื่องมือต่าง ๆ ที่เกี่ยวข้องจะค่อย ๆ ปรับตามมาตรฐานนี้
  • ดูเหมือนว่าจะมีหลายด้านในกระบวนการพัฒนาที่นำไปใช้ได้ เช่น OpenAPI Overlay หรือ Spectral ไม่ได้จำกัดแค่การดึงข้อมูลเท่านั้น แต่ยังนำไปใช้กับการเสริมเอกสาร การตรวจสอบ และการจัดระเบียบข้อมูลได้ด้วย
  • อย่างไรก็ตาม ไวยากรณ์ค่อนข้างซับซ้อนเล็กน้อย และต้องคุ้นเคยกับ JSON/YAML จึงมีอุปสรรคในการเริ่มต้นอยู่บ้าง ควรเริ่มจากวิธีง่าย ๆ แล้วค่อย ๆ เรียนรู้ความสามารถขั้นสูงเพิ่มเติม
  • การใช้เครื่องมือบรรทัดคำสั่งอย่าง jq หรือ yq น่าจะช่วยฝึกได้ดี และการใช้เครื่องมือแบบรวมศูนย์อย่าง Bump.sh ก็น่าจะช่วยเพิ่มประสิทธิภาพการทำงานได้

2 ความคิดเห็น

 
greenhead 2024-05-05

ขอบคุณ

 
GN⁺ 2024-05-05
ความคิดเห็นใน Hacker News
  • JSONata(https://jsonata.org) เป็นหนึ่งในเครื่องมือที่ดีที่สุดสำหรับจัดการ JSON โดยใช้ไวยากรณ์ JsonPath และนอกจากการเลือกโหนดแล้ว ยังมีฟังก์ชันช่วยสำหรับการคำนวณเชิงคณิตศาสตร์ การเปรียบเทียบ การเรียงลำดับ การจัดกลุ่ม การจัดการวันที่ และการสรุปรวม เขียนด้วย JS จึงใช้ได้ทั้งบน Node หรือในเบราว์เซอร์ และยังมี Python wrapper (https://pypi.org/project/pyjsonata/) ด้วย

  • json_profile(https://github.com/tylerneylon/json_profile) เป็นเครื่องมือที่ช่วยให้เข้าใจสคีมาหลักและตำแหน่งข้อมูลของไฟล์ JSON ใหม่ได้อย่างรวดเร็ว โดยมีประโยชน์เมื่อองค์ประกอบระดับเดียวกันในลิสต์มีโครงสร้างเหมือนกัน มันจะเรียนรู้โครงสร้างของไฟล์ แสดงเส้นทางการสรุปรวมที่หนักที่สุด และให้คำใบ้เรื่องขนาดแยกตามแต่ละเส้นทาง

  • espath(https://github.com/tomhodgins/espath) เป็นไลบรารีที่ใช้ XPath และ CSS selector เพื่อกรองและค้นหาข้อมูลใน JSON โดยทำงานด้วยการแปลง JavaScript object เป็น XML DOM แล้วรันคิวรีก่อนจะแปลงกลับเป็น object อีกครั้ง หรือทำงานโดยคงรีจิสเตอร์ของ object ต้นฉบับไว้และค้นคืน object ต้นฉบับ

  • มีคำถามว่ามีชื่อเรียกทั่วไปสำหรับโครงสร้างข้อมูลที่ JSON แทนอยู่หรือไม่ และมีการพูดถึงความจำเป็นของภาษาสำหรับระบุเส้นทางที่ทำงานได้กับโครงสร้างคล้ายกันอย่าง JSON, YAML, Python dictionary, TOML เป็นต้น

  • SQLite รวมส่วนย่อยของ JSON Path ไว้ในแกนฐานข้อมูล โดยใช้ในฟังก์ชันอย่าง json_extract() บันทึกรายละเอียดที่เกี่ยวข้อง: https://til.simonwillison.net/sqlite/json-extract-path

  • Insomnia และ Bruno มีความสามารถในการใช้ JSON Path เพื่อกรองการตอบกลับ

  • เคยนำการรองรับ jsonpath ของ PostgreSQL ไปใช้สร้างกฎการกรองแบบกำหนดเองสำหรับแถวในฐานข้อมูล

  • คาดว่าการโจมตีแบบ JSON path injection จะหลีกเลี่ยงไม่ได้ เหมือนที่ XPATH injection เคยถูกใช้กันอย่างแพร่หลาย (ดู https://owasp.org/www-community/attacks/XPATH_Injection)

  • น่าแปลกที่ไม่มีการกล่าวถึงเครื่องมือคล้ายกันอย่าง jq

  • น่าเสียดายที่มีไวยากรณ์ JSON path มากเกินไป ทั้ง jq, JSON path, AWS CLI, MySQL ฯลฯ ต่างก็ใช้ไวยากรณ์คนละแบบ ทำให้สร้าง muscle memory ได้ยาก