หมวดหมู่: REST

เราจะใช้ Method GET ในการเรียกข้อมูลจาก server แต่

🚀 RESTful Method GET: มาตรฐานและความท้าทายในโลกใช้งานจริง

ในสถาปัตยกรรม REST ( Representational State Transfer ) นั้น GET คือหัวใจหลักที่ใช้สำหรับการ “ดึงข้อมูล” ( Retrieve Resource ) โดยมีกฎเหล็กคือต้องเป็น Safe ( ไม่เปลี่ยนแปลงข้อมูลบน Server ) และ Idempotent ( เรียกกี่ครั้งก็ได้ผลลัพธ์เหมือนเดิม ถ้าข้อมูลไม่เปลี่ยน )

โดยปกติเราจะส่งเงื่อนไขการกรองข้อมูล ( Filtering ) ผ่านสิ่งที่เรียกว่า Query Parameters เช่น: GET /api/products?category=electronics&min_price=1000&sort=desc

🛑 เมื่อ GET เริ่ม “เอาไม่อยู่” ( The Limitation )

เมื่อคุณใช้งาน Library จัดการตารางอย่าง DataTables หรือ Tabulator ในโหมด Server-side Processing ตัว Library จะส่งพารามิเตอร์ไปหา Server จำนวนมาก เช่น

• ลำดับคอลัมน์ ( Columns metadata )
• สถานะการ Search ของแต่ละคอลัมน์ ( Individual column filtering )
• การเรียงลำดับ ( Multi-column sorting )
• เลขหน้า ( Pagination )

ปัญหาที่ตามมา

1. URL Length Limit: Browser ส่วนใหญ่และ Web Server อย่าง Nginx มักจำกัดความยาว URL ไว้ที่ประมาณ 2,000 – 8,000 ตัวอักษร หาก Filter ยาวเกินไป Request จะถูกตัดทิ้ง ( Error 414 Request-URI Too Large )
2. Readability & Logs: URL ที่ยาวเป็นกิโลเมตรทำให้อ่าน Log ยาก และอาจหลุดข้อมูลสำคัญไปอยู่ใน History ของ Browser ได้
3. Special Characters: การส่ง Array หรือ Object ซับซ้อนผ่าน URL ต้องทำการ Encode ( URL Encoding ) จนทำให้อ่านค่าได้ลำบาก

🔄 ทางออก: การใช้ POST แทน GET ( The Pragmatic Approach )

แม้ตามทฤษฎี RESTful จะบอกว่าการดึงข้อมูลควรใช้ GET แต่ในทางปฏิบัติเมื่อ Filter มีความซับซ้อน ( Complex Search ) เรานิยมขยับมาใช้ POST เพื่อส่งเงื่อนไขผ่าน Request Body แทน

ตัวอย่างการประยุกต์ใช้กับ Library ยอดนิยม

DataTables ( jQuery )

DataTables มีความยืดหยุ่นสูง เพียงแค่เปลี่ยน type ในส่วนของ ajax ข้อมูลพารามิเตอร์ทั้งหมดจะถูกย้ายจาก URL ไปอยู่ใน Payload ของ POST ทันที

$('#exampleTable').DataTable({
    serverSide: true,
    ajax: {
        url: '/api/resource/search',
        type: 'POST', // เปลี่ยนจาก GET เป็น POST
        data: function (d) {
            // d คือ Object ขนาดใหญ่ที่ DataTables สร้างให้โดยอัตโนมัติ
            return JSON.stringify(d); 
        },
        contentType: "application/json; charset=utf-8",
    }
});

Tabulator

Tabulator ออกแบบมาให้รองรับ JSON เป็นหลัก การเปลี่ยนมาใช้ POST จึงทำได้สะอาดตามาก

var table = new Tabulator("#example-table", {
    ajaxURL: "/api/resource/search",
    ajaxConfig: "POST",          // ใช้ POST เพื่อส่ง Body
    ajaxContentType: "json",     // ส่งข้อมูลในรูปแบบ JSON
    pagination: "remote",        // ให้ Server จัดการแบ่งหน้า
    filterMode: "remote",        // ให้ Server จัดการ Filter
});

📝 ตารางเปรียบเทียบ: GET vs POST สำหรับ Filtering

Gemini บอกว่า

นี่คือบทความสรุปเนื้อหาเกี่ยวกับ RESTful Method GET และแนวทางการปรับเปลี่ยนมาใช้ POST เมื่อต้องรับมือกับข้อมูล Filter จำนวนมหาศาลครับ

🚀 RESTful Method GET: มาตรฐานและความท้าทายในโลกใช้งานจริง

ในสถาปัตยกรรม REST (Representational State Transfer) นั้น GET คือหัวใจหลักที่ใช้สำหรับการ “ดึงข้อมูล” (Retrieve Resource) โดยมีกฎเหล็กคือต้องเป็น Safe (ไม่เปลี่ยนแปลงข้อมูลบน Server) และ Idempotent (เรียกกี่ครั้งก็ได้ผลลัพธ์เหมือนเดิม ถ้าข้อมูลไม่เปลี่ยน)

โดยปกติเราจะส่งเงื่อนไขการกรองข้อมูล (Filtering) ผ่านสิ่งที่เรียกว่า Query Parameters เช่น: GET /api/products?category=electronics&min_price=1000&sort=desc

🛑 เมื่อ GET เริ่ม “เอาไม่อยู่” (The Limitation)

เมื่อคุณใช้งาน Library จัดการตารางอย่าง DataTables หรือ Tabulator ในโหมด Server-side Processing ตัว Library จะส่งพารามิเตอร์ไปหา Server จำนวนมาก เช่น:

• ลำดับคอลัมน์ (Columns metadata)
• สถานะการ Search ของแต่ละคอลัมน์ (Individual column filtering)
• การเรียงลำดับ (Multi-column sorting)
• เลขหน้า (Pagination)

ปัญหาที่ตามมา:

1. URL Length Limit: Browser ส่วนใหญ่และ Web Server อย่าง Nginx มักจำกัดความยาว URL ไว้ที่ประมาณ 2,000 – 8,000 ตัวอักษร หาก Filter ยาวเกินไป Request จะถูกตัดทิ้ง (Error 414 Request-URI Too Large)
2. Readability & Logs: URL ที่ยาวเป็นกิโลเมตรทำให้อ่าน Log ยาก และอาจหลุดข้อมูลสำคัญไปอยู่ใน History ของ Browser ได้
3. Special Characters: การส่ง Array หรือ Object ซับซ้อนผ่าน URL ต้องทำการ Encode (URL Encoding) จนทำให้อ่านค่าได้ลำบาก

🔄 ทางออก: การใช้ POST แทน GET (The Pragmatic Approach)

แม้ตามทฤษฎี RESTful จะบอกว่าการดึงข้อมูลควรใช้ GET แต่ในทางปฏิบัติเมื่อ Filter มีความซับซ้อน (Complex Search) เรานิยมขยับมาใช้ POST เพื่อส่งเงื่อนไขผ่าน Request Body แทน

ตัวอย่างการประยุกต์ใช้กับ Library ยอดนิยม

1. DataTables (jQuery)

DataTables มีความยืดหยุ่นสูง เพียงแค่เปลี่ยน type ในส่วนของ ajax ข้อมูลพารามิเตอร์ทั้งหมดจะถูกย้ายจาก URL ไปอยู่ใน Payload ของ POST ทันที

JavaScript

$('#exampleTable').DataTable({
    serverSide: true,
    ajax: {
        url: '/api/resource/search',
        type: 'POST', // เปลี่ยนจาก GET เป็น POST
        data: function (d) {
            // d คือ Object ขนาดใหญ่ที่ DataTables สร้างให้โดยอัตโนมัติ
            return JSON.stringify(d); 
        },
        contentType: "application/json; charset=utf-8",
    }
});

2. Tabulator

Tabulator ออกแบบมาให้รองรับ JSON เป็นหลัก การเปลี่ยนมาใช้ POST จึงทำได้สะอาดตามาก

JavaScript

var table = new Tabulator("#example-table", {
    ajaxURL: "/api/resource/search",
    ajaxConfig: "POST",          // ใช้ POST เพื่อส่ง Body
    ajaxContentType: "json",     // ส่งข้อมูลในรูปแบบ JSON
    pagination: "remote",        // ให้ Server จัดการแบ่งหน้า
    filterMode: "remote",        // ให้ Server จัดการ Filter
});

📝 ตารางเปรียบเทียบ: GET vs POST สำหรับ Filtering

⚠️ ข้อควรระวังสำหรับ System Admin ( Nginx User )

หากคุณตัดสินใจเปลี่ยนมาใช้ POST เพื่อรับส่งข้อมูล JSON ขนาดใหญ่ อย่าลืมตรวจสอบค่าคอนฟิกใน Nginx

• client_max_body_size: หาก JSON ก้อนนั้นใหญ่เกิน 1MB ( ค่าเริ่มต้น ) Nginx จะส่ง Error 413 กลับมา คุณควรปรับเพิ่ม เช่น client_max_body_size 10M;
• CSRF Protection: ในฝั่ง Backend หากคุณใช้ Framework ( Laravel, Django ) ต้องแน่ใจว่าได้ยกเว้น Route นี้จาก CSRF หรือส่ง Token ไปด้วย เพราะ POST มักถูกตรวจสอบความปลอดภัยเข้มงวดกว่า GET

อ่านเพิ่มเติม

• RESTful ( Representational State Transfer )
• RESTful: update data
• NGINX: test configuration
• NGINX: Headers More