REST API: คืออะไร วิธี HTTP และหลักการทำงานในแอปพลิเคชันมือถือ

REST API คืออะไร?

REST API (API การถ่ายโอนสถานะเชิงตัวแทน) เป็นรูปแบบสถาปัตยกรรมที่เสนอโดยรอย ฟีลดิงในวิทยานิพนธ์ระดับปริญญาเอกของเขาในปี 2000 โดยกำหนดชุดข้อจำกัดและหลักการสำหรับการออกแบบโปรโตคอลเครือข่าย API ที่ปฏิบัติตามข้อจำกัดเหล่านี้เรียกว่า RESTful REST ไม่ใช่โปรโตคอลหรือมาตรฐาน — เป็นแนวทางทางสถาปัตยกรรมที่ใช้โปรโตคอลที่มีอยู่ (ส่วนใหญ่เป็น HTTP) สำหรับการแลกเปลี่ยนข้อมูลระหว่างไคลเอ็นต์และเซิร์ฟเวอร์

แนวคิดหลักของ REST คือ สถาปัตยกรรมที่เน้นทรัพยากร แทนที่จะเรียกเมธอดบนเซิร์ฟเวอร์ (เช่นใน SOAP หรือ RPC) ไคลเอ็นต์จะดำเนินการกับทรัพยากร: รับรายการ สร้างใหม่ อัปเดตหรือลบ ทรัพยากรแต่ละรายการคือเอนทิตีของโดเมน: ผู้ใช้ คำสั่งซื้อ สินค้า บทความ ทรัพยากรมีสถานะซึ่งถูกส่งไปยังไคลเอ็นต์ในรูปแบบมาตรฐาน โดยปกติคือ JSON เซิร์ฟเวอร์ไม่เก็บสถานะของไคลเอ็นต์ระหว่างคำขอ — นี่คือหลักการ stateless ข้อกำหนดสำคัญของ REST

คุณลักษณะหลักของ REST API:

• Stateless — แต่ละคำขอจากไคลเอ็นต์มีข้อมูลทั้งหมดที่จำเป็นสำหรับการประมวลผล
• Cacheable — การตอบสนองของเซิร์ฟเวอร์ต้องถูกทำเครื่องหมายอย่างชัดเจนว่าสามารถแคชได้หรือไม่
• Layered system — สถาปัตยกรรมสามารถรวมเซิร์ฟเวอร์กลาง ตัวปรับสมดุลโหลด พร็อกซี
• Uniform interface — อินเทอร์เฟซการโต้ตอบแบบรวมผ่านวิธี HTTP, URL และรหัสสถานะ

หลักการของสถาปัตยกรรม REST

REST อิงตามข้อจำกัดทางสถาปัตยกรรมหกประการที่ฟีลดิงกำหนดขึ้น การปฏิบัติตามข้อจำกัดเหล่านี้ช่วยให้มั่นใจในความสามารถในการปรับขนาด ประสิทธิภาพ และความง่ายในการรวมระบบ แต่ละหลักการแก้ปัญหาเฉพาะของระบบกระจาย — จากความจำเป็นในการแคชไปจนถึงข้อกำหนดด้านความปลอดภัย มาดูแต่ละหลักการอย่างละเอียดกัน

หลักการ Uniform Interface ยังรวมข้อจำกัดย่อยสี่ประการ: การระบุทรัพยากรผ่าน URI การจัดการทรัพยากรผ่านตัวแทน ข้อความที่อธิบายตนเองได้ และ HATEOAS (ไฮเปอร์มีเดียเป็นกลไกของสถานะแอปพลิเคชัน) ข้อจำกัดย่อยสุดท้ายมักถูกมองข้ามในทางปฏิบัติ — REST API สมัยใหม่ส่วนใหญ่ไม่ได้ใช้ HATEOAS อย่างสมบูรณ์ ซึ่งนำไปสู่การอภิปรายว่า API ดังกล่าวเป็น RESTful “อย่างแท้จริง” หรือไม่

หลักการ Stateless เป็นหนึ่งในหลักการที่สำคัญที่สุดสำหรับการปรับขนาด การไม่มีเซสชันบนเซิร์ฟเวอร์หมายความว่าอินสแตนซ์เซิร์ฟเวอร์ใดๆ ก็สามารถประมวลผลคำขอใดๆ ได้ ซึ่งช่วยลดความซับซ้อนของการปรับขนาดแนวนอน: เพียงเพิ่มเซิร์ฟเวอร์ใหม่หลังตัวปรับสมดุลโหลด สำหรับแอปพลิเคชันมือถือ stateless ยังหมายความว่าคำขอสามารถส่งไปยังเซิร์ฟเวอร์ CDN ใดก็ได้ ซึ่งมีความสำคัญต่อการเข้าถึงทั่วโลก

วิธี HTTP ใน REST

แต่ละ วิธี HTTP ใน REST API สอดคล้องกับการดำเนินการเฉพาะบนทรัพยากร: GET สำหรับการอ่าน POST สำหรับการสร้าง PUT สำหรับการอัปเดตทั้งหมด PATCH สำหรับการอัปเดตบางส่วน DELETE สำหรับการลบ ความเป็นเอกภาพ (idempotence) ของวิธีเป็นคุณลักษณะสำคัญ: GET, PUT, DELETE เป็นเอกภาพ (การดำเนินการซ้ำให้ผลลัพธ์เดียวกัน) POST และ PATCH ไม่เป็น นี่เป็นสิ่งสำคัญสำหรับการจัดการข้อผิดพลาดเครือข่ายเมื่อไคลเอ็นต์ไม่ทราบว่าคำขอถึงเซิร์ฟเวอร์หรือไม่

• GET — การรับทรัพยากรหรือรายการทรัพยากร เป็นเอกภาพ ไม่เปลี่ยนสถานะเซิร์ฟเวอร์
• POST — การสร้างทรัพยากรใหม่ ไม่เป็นเอกภาพ แต่ละการเรียกสร้างทรัพยากรใหม่
• PUT — การแทนที่ทรัพยากรทั้งหมด เป็นเอกภาพ การเรียกซ้ำไม่เปลี่ยนสถานะหลังจากครั้งแรก
• PATCH — การอัปเดตทรัพยากรบางส่วน เป็นเอกภาพบางส่วน (ขึ้นอยู่กับการนำไปใช้)
• DELETE — การลบทรัพยากร เป็นเอกภาพ การลบซ้ำคืนค่า 404 ไม่ใช่ข้อผิดพลาด

รหัสสถานะ HTTP เป็นส่วนสำคัญของ REST API แต่ละรหัสมีความหมายเฉพาะ: 200 OK สำหรับ GET ที่สำเร็จ 201 Created สำหรับ POST 204 No Content สำหรับ DELETE ที่ไม่มีเนื้อหาการตอบสนอง 400 Bad Request สำหรับข้อมูลไม่ถูกต้อง 401 Unauthorized สำหรับขาดการรับรองตัวตน 404 Not Found สำหรับทรัพยากรไม่พบ การใช้รหัสสถานะอย่างถูกต้องทำให้ API สามารถอธิบายตนเองได้และช่วยให้การดีบักง่ายขึ้น

รูปแบบข้อมูล: JSON และอื่นๆ

JSON (สัญกรณ์วัตถุ JavaScript) เป็นรูปแบบหลักสำหรับการถ่ายโอนข้อมูลใน REST API ความนิยมของมันเกิดจากความเรียบง่าย อ่านง่าย และการสนับสนุนดั้งเดิมใน JavaScript JSON ถูกส่งด้วยหัวข้อ Content-Type: application/json ทางเลือกอื่นรวมถึง XML (ละเอียด ล้าสมัย) YAML (สะดวกสำหรับการกำหนดค่า พบน้อยกว่าสำหรับ API) และ Protocol Buffers (ไบนารี มีประสิทธิภาพสำหรับระบบที่มีโหลดสูง)

โครงสร้างของวัตถุ JSON ใน REST API โดยทั่วไปรวมถึงฟิลด์ id, type และแอตทริบิวต์ของทรัพยากร สำหรับคอลเล็กชัน จะใช้อาร์เรย์ JSON พร้อมเมตาดาตาการแบ่งหน้า REST API สมัยใหม่ปฏิบัติตามข้อกำหนด JSON:API (jsonapi.org) หรือ JSON Schema สำหรับการตรวจสอบความถูกต้องของการตอบสนอง การใช้รูปแบบข้อมูลแบบรวมช่วยลดความซับซ้อนของการพัฒนาไลบรารีไคลเอ็นต์และการสร้างเอกสาร

ตัวอย่างการตอบสนอง JSON สำหรับรายการผู้ใช้:

{
    "data": [
        {
            "id": 1,
            "name": "อันนา เปโตรวา",
            "email": "anna@example.com"
        }
    ],
    "meta": {
        "total": 42,
        "page": 1,
        "per_page": 10
    }
}

การเลือกรูปแบบการถ่ายโอนข้อมูลส่งผลต่อประสิทธิภาพของแอปพลิเคชันมือถือ JSON ถูกบีบอัดผ่าน GZIP ได้ 70-80% ทำให้ยอมรับได้สำหรับสถานการณ์ส่วนใหญ่ สำหรับแอปพลิเคชันเรียลไทม์ที่มีปริมาณข้อมูลมาก (สตรีมมิ่ง เกม) แนะนำให้เปลี่ยนเป็นโปรโตคอลไบนารีหรือใช้ WebSocket ร่วมกับ Protocol Buffers

ตัวอย่างคำขอ REST API

มาดูตัวอย่างเชิงปฏิบัติของการทำงานกับ REST API ในฝั่งแอปพลิเคชันมือถือกัน เป็นตัวอย่าง สมมติว่าเรามี API สำหรับทำงานกับคำสั่งซื้อในร้านค้าออนไลน์ สำหรับแต่ละวิธี HTTP จะแสดงคำขอและการตอบสนองที่คาดหวังจากเซิร์ฟเวอร์ ตัวอย่างแสดงโครงสร้าง RESTful API ทั่วไปที่ใช้ในการพัฒนาแอปมือถือ

GET — การรับรายการคำสั่งซื้อ

คำขอเพื่อรับคำสั่งซื้อทั้งหมดของผู้ใช้พร้อมการแบ่งหน้า การตอบสนองประกอบด้วยอาร์เรย์ของวัตถุคำสั่งซื้อและข้อมูลเมตาสำหรับการนำทางระหว่างหน้า พารามิเตอร์ page และ per_page ถูกส่งผ่าน query string

// อินเทอร์เฟซ Retrofit สำหรับ REST API
interface OrderApi {
    @GET("api/v1/orders")
    suspend fun getOrders(
        @Query("page") page: Int = 1,
        @Query("per_page") perPage: Int = 20
    ): Response<OrderListResponse>
}

POST — การสร้างคำสั่งซื้อใหม่

การสร้างคำสั่งซื้อใหม่ผ่านคำขอ POST เซิร์ฟเวอร์คืนสถานะ 201 Created และวัตถุที่สร้างขึ้นในเนื้อหาการตอบสนอง สำคัญ: การสร้างทำบนคอลเล็กชัน /api/v1/orders ไม่ใช่บนทรัพยากรเฉพาะ — นี่เป็นรูปแบบ RESTful มาตรฐาน

@POST("api/v1/orders")
suspend fun createOrder(
    @Body order: CreateOrderRequest
): Response<OrderResponse>

// ตัวอย่างเนื้อหาคำขอ
data class CreateOrderRequest(
    val productId: String,
    val quantity: Int,
    val addressId: String
)

DELETE — การลบคำสั่งซื้อ

การลบทรัพยากรทำด้วยวิธี DELETE บน URL เฉพาะของคำสั่งซื้อ การลบสำเร็จคืนค่า 204 No Content ความเป็นเอกภาพของ DELETE หมายความว่าคำขอซ้ำไปยัง URL เดียวกันคืนค่า 404 Not Found ซึ่งได้รับการจัดการอย่างถูกต้องบนไคลเอ็นต์

@DELETE("api/v1/orders/{id}")
suspend fun deleteOrder(
    @Path("id") orderId: String
): Response<Unit>

// การใช้งานใน ViewModel
fun removeOrder(orderId: String) {
    viewModelScope.launch {
        val response = api.deleteOrder(orderId)
        if (response.isSuccessful) {
            showSuccess()
        }
    }
}

ตัวอย่างเหล่านี้แสดงการนำ REST API ไปใช้ทั่วไปในฝั่ง Android โดยใช้ Retrofit และ Kotlin Coroutines สำหรับแอปพลิเคชัน iOS URLSession หรือไลบรารี Alamofire ร่วมกับโปรโตคอล Codable มีบทบาทคล้ายกัน โครงสร้าง REST API ยังคงเหมือนเดิมโดยไม่ขึ้นกับแพลตฟอร์ม — เฉพาะวิธีการดำเนินการขอเท่านั้นที่เปลี่ยนไป

การออกแบบ RESTful API: คำแนะนำเชิงปฏิบัติ

การออกแบบ RESTful API ที่มีคุณภาพสูงต้องการปฏิบัติตามธรรมเนียมที่ทำให้ API เข้าใจง่ายสำหรับนักพัฒนา ทรัพยากรควรตั้งชื่อด้วยคำนามพหูพจน์ (/users, /orders, /products) วิธี HTTP ควรสะท้อนถึงการดำเนินการ และ URL ควรแสดงลำดับชั้นการซ้อนกัน ข้อผิดพลาดควรคืนค่า JSON ที่เป็นมาตรฐานพร้อมรหัสและข้อความ ไม่ใช่แค่สถานะ HTTP การปฏิบัติตามธรรมเนียมเหล่านี้ช่วยลดอุปสรรคในการเข้าสำหรับนักพัฒนาใหม่และทำให้การรวมระบบง่ายขึ้น

• การตั้งชื่อทรัพยากร — พหูพจน์, kebab-case: /api/v1/user-orders, ไม่ใช่ /api/v1/getUserOrders
• การกรองและเรียงลำดับ — ผ่านพารามิเตอร์ query: ?status=active&sort=created_at:desc
• การแบ่งหน้า — แบบเคอร์เซอร์สำหรับชุดใหญ่ แบบหน้าสำหรับชุดเล็ก
• การจัดการเวอร์ชัน — ผ่าน URL (/api/v2/) หรือหัวข้อ Accept-Version
• ข้อผิดพลาด — รูปแบบรวม: { "error": { "code": "VALIDATION_ERROR", "message": "..." } }
• การจำกัดอัตรา — หัวข้อ X-RateLimit-Remaining และ Retry-After

ข้อผิดพลาดทั่วไปอย่างหนึ่งในการออกแบบ REST API คือการซ้อนทรัพยากรมากเกินไป แทนที่จะใช้ /users/1/orders/5/items/3 ควรใช้โครงสร้างแบบราบกับพารามิเตอร์ query: /items?order_id=5&user_id=1 ซึ่งช่วยให้การแคชง่ายขึ้น ไม่ต้องการการดูแลเส้นทางยาวบนเซิร์ฟเวอร์ และจัดทำเอกสารได้ง่ายกว่า สถาปัตยกรรมแบบราบยังเข้ากันได้ดีกว่ากับคำค้นหาแบบกราฟเมื่อย้ายไปใช้ GraphQL ในอนาคต

ความปลอดภัยของ REST API ถูกนำไปใช้ผ่าน การรับรองตัวตน (JWT, OAuth 2.0) และ การอนุญาต ในระดับทรัพยากร แต่ละคำขอต้องตรวจสอบว่าผู้ใช้มีสิทธิ์เข้าถึงทรัพยากรที่ร้องขอหรือไม่ HTTPS เป็นข้อบังคับ — หากไม่มีการเข้ารหัส โทเค็นและข้อมูลจะถูกส่งในรูปแบบข้อความธรรมดา สำหรับแอปพลิเคชันมือถือ แนะนำให้ใช้ OAuth 2.0 กับ PKCE (Proof Key for Code Exchange) เพื่อรับโทเค็นอย่างปลอดภัย

การจัดการเวอร์ชันและการแคช

การจัดการเวอร์ชัน ของ REST API จำเป็นสำหรับความเข้ากันได้ย้อนหลังเมื่อมีการเปลี่ยนแปลง วิธีการที่พบบ่อยที่สุดคือ: เวอร์ชันใน URL (/api/v1/orders) เวอร์ชันในหัวข้อ (Accept: application/vnd.myapi.v1+json) และเวอร์ชันในพารามิเตอร์ query (?api_version=1) การจัดการเวอร์ชันด้วย URL เป็นวิธีที่ได้รับความนิยมมากที่สุดเนื่องจากมองเห็นได้ชัดเจนในบันทึกและเอกสาร อย่างไรก็ตาม มันละเมิดหลักการ REST ของ URL เดียวต่อทรัพยากร

การแคช ใน REST API ถูกนำไปใช้ผ่านหัวข้อ HTTP Cache-Control, ETag และ Last-Modified คำขอ GET ที่ถูกทำเครื่องหมายว่าสามารถแคชได้สามารถให้บริการจากแคชของเบราว์เซอร์หรือพร็อกซีโดยไม่ต้องติดต่อเซิร์ฟเวอร์ สำหรับแอปพลิเคชันมือถือ การแคชมีความสำคัญเป็นพิเศษ — ช่วยลดการใช้ข้อมูลและเพิ่มความเร็วในการแสดงข้อมูลที่โหลดไว้ก่อนหน้าเมื่อการเชื่อมต่อไม่ดี ETag คือแฮชของเนื้อหาการตอบสนอง: ไคลเอ็นต์ส่งใน If-None-Match และเซิร์ฟเวอร์คืนค่า 304 Not Modified หากข้อมูลไม่เปลี่ยนแปลง

ทางเลือกสมัยใหม่ของ REST API รวมถึง GraphQL (การดึงข้อมูลที่ยืดหยุ่นฝั่งไคลเอ็นต์) และ gRPC (โปรโตคอลไบนารีบน HTTP/2 สำหรับไมโครเซอร์วิส) อย่างไรก็ตาม REST ยังคงเป็นมาตรฐานหลักสำหรับ API สาธารณะเนื่องจากความเรียบง่าย ความเป็นสากล และการสนับสนุนเครื่องมือที่กว้างขวาง การเลือกระหว่าง REST และทางเลือกอื่นขึ้นอยู่กับข้อกำหนดเฉพาะของโครงการ: ความซับซ้อนของคำค้นหา ปริมาณข้อมูล ความต้องการอัปเดตแบบเรียลไทม์