วิธีที่ใช้สำนวนในการจัดการเวอร์ชัน api คืออะไร [ปิด]

ฉันกำลังสร้างเซิร์ฟเวอร์ใน Go สำหรับแอปมือถือ ฉันต้องสามารถรองรับ API ได้หลายเวอร์ชันในกรณีที่ผู้ใช้ไม่ได้อัปเดตแอป ข้อกังวลหลักของการกำหนดเวอร์ชันคือการส่งคืนข้อมูลในรูปแบบที่ถูกต้องสำหรับเวอร์ชันของแอปบนมือถือ

ฉันเห็นว่ามีวิธีพื้นฐานสามวิธีในการทำเช่นนี้
ก. วิธีหนึ่งคือการมีตัวจัดการเส้นทางหนึ่งตัวบน / จากนั้นอนุญาตให้ฟังก์ชันนั้นแยกวิเคราะห์ URL สำหรับการกำหนดเวอร์ชัน
ตัวอย่าง:

func main() {
http.HandleFunc("/", routes.ParseFullURI)
}

B. ใช้ไลบรารี เช่น gorilla/mux เพื่อจัดการรูปแบบภายในเราเตอร์ แต่ฉันเห็น คำเตือนว่าการดำเนินการนี้อาจช้าเกินไป.
ตัวอย่าง:

  func main() {
            mux.HandleFunc("{version:}/", routes.ParseVersionForHome)
            mux.HandleFunc("{version:}/getData", routes.ParseVersionForGetDAta)
            mux.HandleFunc("{version:}/otherCall", routes.ParseVersionForOtherCall)
            }

C. มี URL แต่ละรายการที่ไม่เปลี่ยนแปลง แต่แยกตามส่วนหัวออกเป็นเวอร์ชันต่างๆ ตัวอย่าง:

func main() {
   http.HandleFunc("/", routes.ParseHeaderForVersionForHome)
   http.HandleFunc("/getData", routes.ParseHeaderForVersionForGetData)
   http.HandleFunc("/otherCall", routes.ParseHeaderForVersionForOtherCall)
}

ฉันกังวลว่าตัวเลือกที่ 1 จะเป็นรหัสที่ยุ่งเกินไป ฉันกังวลว่าตัวเลือกที่ 2 จะทำงานช้าเกินไป และฉันกังวลว่าตัวเลือกที่ 3 จะยากสำหรับลูกค้าที่จะจัดการ หรืออาจสร้างความสับสนเนื่องจากเวอร์ชันไม่มีป้ายกำกับชัดเจน

วิธีใดที่เป็นสำนวนมากที่สุดสำหรับ Go และจะส่งผลให้แอปบนอุปกรณ์เคลื่อนที่มีประสิทธิภาพสูงสุดซึ่งจะมีการสำรวจบ่อยครั้ง


go routes versioning
person Avik    schedule 21.04.2015    source แหล่งที่มา
comment
หากคุณกำลังพูดถึง API บน HTTP(S) บางอย่างเช่น http://example.com/api/v1/… ก็เป็นเรื่องปกติ หรือคุณกำลังถามว่าจะใช้รูปแบบดังกล่าวในเซิร์ฟเวอร์ Go ได้อย่างไร?   -  person Dave C    schedule 21.04.2015
comment
ฉันกำลังถามว่าจะทำอย่างไรใน Go Server ฉันจะอธิบายเพิ่มเติมในคำถามของฉัน   -  person Avik    schedule 21.04.2015
comment
โดยพื้นฐานแล้ว 1 และ 2 นั้นเทียบเท่ากัน คุณแค่กำหนดเส้นทางด้วยตัวเองในตอนแรก หาก gorilla/mux ช้าเกินไป อย่าใช้มัน (แม้แต่ HandleFunc เริ่มต้นก็ยังใช้เราเตอร์: http.ServeMux) 3 ไม่มีส่วนเกี่ยวข้องกับ Go เพียงแต่คุณต้องการให้ลูกค้าของคุณใช้ส่วนหัวหรือไม่ (ซึ่งไม่ใช่เรื่องใหญ่)   -  person JimB    schedule 21.04.2015
comment
3 เกี่ยวข้องกับ Go เพราะมันกำหนดเส้นทางที่เป็นไปได้ในคลาสอย่างชัดเจน แทนที่จะใช้งานฟังก์ชัน เช่น. คุณเห็นรายการ API ที่รองรับที่ไหน ฉันจะอธิบายให้ชัดเจนยิ่งขึ้นในตัวอย่าง   -  person Avik    schedule 21.04.2015
comment
เราเตอร์หลายตัวจะอนุญาตให้จัดกลุ่มเส้นทางที่แตกต่างกันได้ คุณอาจต้องการตรวจสอบสิ่งนั้น   -  person placeybordeaux    schedule 21.04.2015
comment
@placeybordeaux ขอบคุณครับ นั่นทำให้ฉันมาถึงสิ่งนี้: stackoverflow.com/questions/25298646/ อาจเป็นทิศทางที่ถูกต้องได้อย่างไร คุณต้องการที่จะเปลี่ยนสิ่งนั้นให้เป็นคำตอบที่สมบูรณ์หรือไม่? ต้องไปดูว่าโกจิมีเกณฑ์มาตรฐานหรือไม่   -  person Avik    schedule 21.04.2015
comment
อย่าวิตกเกี่ยวกับความเร็วของเราเตอร์ ที่ https://github.com/julienschmidt/go-http-routing-benchmark คุณจะเห็น การกำหนดเวลา (สำหรับเส้นทางการวัดประสิทธิภาพคำขอเดียว) ในหน่วยพันนาโนวินาที เช่น ในหน่วยไมโครวินาที ในหน่วยพันของมิลลิวินาที นั่นเป็นค่าใช้จ่ายที่น้อยมากเมื่อเทียบกับฐานข้อมูลที่เขียนจนเป็นเรื่องยากสำหรับฉันที่จะเข้าใจโดยสัญชาตญาณ   -  person twotwotwo    schedule 21.04.2015
comment
(เพื่อให้ชัดเจน ฉันคิดว่า echo เป็นความสำเร็จที่ยอดเยี่ยม! เจ๋งมากที่ได้เห็นส่วนประกอบที่ไม่ได้จัดสรรที่ไม่สำคัญ แต่ฉันไม่อยากให้ใครรู้สึกว่าพวกเขาต้องใช้มันเพื่อให้ได้ประสิทธิภาพ API ที่ดี)   -  person twotwotwo    schedule 21.04.2015
comment
@ twotwotwo ฉันจะใช้ redis เป็นฐานข้อมูล ดังนั้นฉันต้องแน่ใจว่าการแยกวิเคราะห์ URL ไม่ใช่คอขวด   -  person Avik    schedule 21.04.2015
comment
@Avik มันจะไม่เป็นอย่างนั้นอย่างแน่นอน การพูดคุยกับ Redis จะเป็นลำดับความสำคัญ (หลักเดียวถึงสิบมิลลิวินาที) ช้ากว่าเส้นทางของคุณ แม้ว่าจะมีเส้นทางมากกว่า 5,000 เส้นทาง เราเตอร์ของคุณก็ยังไม่เข้าใกล้เส้นทางนั้นด้วยซ้ำ โปรดทราบว่า Echo ไม่ จัดสรร - มันสร้างพูล การใช้พูล (รับ/วาง) จะไม่นับรวมกับเอาต์พุตการจัดสรรเบนช์มาร์ก   -  person elithrar    schedule 22.04.2015
comment
@elithrar ตอนนี้ฉันสับสนแล้ว Redis ทำคำขอประมาณ 72 รายการต่อมิลลิวินาที Echo ได้รับการวัดประสิทธิภาพที่ 4.5 มิลลิวินาทีต่อคำขอตามตัวแปรหรือไม่ ฉันอ่านตัวเลขผิดหรือเปล่า?   -  person Avik    schedule 22.04.2015

คำตอบ (1)


arrow_upward
7
arrow_downward

มีเฟรมเวิร์กการกำหนดเส้นทางจำนวนมากที่อนุญาตให้จัดกลุ่มได้ เช่น กับ echo (เฟรมเวิร์กที่ดีมากถ้าคุณต้องการความเร็ว)

package main

import "github.com/labstack/echo"

func ping(c *echo.Context) {
        c.String(200, "pong")
}

func main() {
        e := echo.New()

        v1 := e.Group("/v1")
        v1.Get("/ping", ping)

        v2 := e.Group("/v2")
        v2.Get("/ping", ping)

        e.Run(":4444")
}

ฉันคิดว่าที่นี่ค่อนข้างสะอาด

ฉันแน่ใจว่ากรอบการทำงานอื่น ๆ อีกมากมายอนุญาตสำหรับสิ่งนี้ ฉันรู้ความจริงว่ามาร์ตินี่ทำ แต่นั่นไม่ใช่กรอบการทำงานที่เป็นสำนวน...

person placeybordeaux    schedule 21.04.2015
comment
ขอบคุณ. ตอนนี้ฉันแค่ต้องค้นหาไลบรารี่ที่ดีที่สุดสำหรับความต้องการของฉัน แต่ดูเหมือนว่าจะเป็นแนวทางที่ใช้กันทั่วไปที่สุดในการกำหนดเวอร์ชันใน Go รายชื่อไลบรารี่ที่รองรับการจัดกลุ่มและรวดเร็วดูเหมือนไม่มีที่สิ้นสุด! - person Avik; 21.04.2015
comment
สวัสดี ฉันได้ค้นหาข้อมูลในเน็ต และมีปัญหาในการทำความเข้าใจว่า ping เป็นฟังก์ชันเดียวกันหรือไม่ และหากเป็นเช่นนั้น ฉันจะแยกแยะได้อย่างไรว่ากลุ่มใดที่เรียกใช้ฟังก์ชันดังกล่าวเพื่อให้ได้ผลลัพธ์ที่ต่างกัน - person Avik; 26.04.2015
comment
ปิงเป็นฟังก์ชันเดียวกัน จากบริบทของการ ping คุณสามารถค้นหา URL ที่ได้รับ ฉันคิดว่าคุณจะเรียกใช้ฟังก์ชันที่แตกต่างกันสำหรับเวอร์ชันที่แตกต่างกัน - person placeybordeaux; 30.04.2015