API công cộng của mãi mãi là duy nhất: Chỉ có một cơ hội để có được nó đúng không?

Trong một cuốn sách hệ điều hành tôi chỉ đọc rằng, "API công cộng là mãi mãi: Chỉ có một cơ hội để làm cho đúng". Có thật không? Có phải nó chỉ áp dụng trong API của Hệ điều hành hoặc các API khác không? Ví dụ: điều này có đúng với các API của Ứng dụng Android như Tasker, Locale và Pushover không?

Nó thường đúng với mọi API công khai, vâng. Khi bạn đưa API ra công chúng và mọi người bắt đầu xây dựng các ứng dụng phụ thuộc vào API đó, việc thay đổi API trở nên cực kỳ khó khăn vì làm như vậy sẽ phá vỡ tất cả các ứng dụng đó. Đó có xu hướng vừa là một vấn đề kỹ thuật khó khăn vừa là một vấn đề chính trị khó khăn.

Tất nhiên, có thể thay đổi API công khai. Ví dụ, điều đó xảy ra là các dự án sẽ mô tả API trong một bản phát hành, giới thiệu API mới và sau đó xóa API cũ trong một số bản phát hành trong tương lai. Nhưng điều đó giả định rằng mọi ứng dụng (quan trọng) sử dụng API cũ sẽ được viết lại để sử dụng API mới trước khi API cũ bị xóa. Điều đó thường mất nhiều năm. Và điều đó có nghĩa là chủ sở hữu của API công cộng đang áp đặt chi phí cho mọi dự án khác sử dụng API. Vì nhìn chung có nhiều người tiêu dùng API hơn, những người tiêu dùng đó có xu hướng trở thành một hành lang chính trị tương đối mạnh mẽ.

Trích dẫn tác giả là Joshua Bloch, tuyên bố là từ bài viết Thiết kế API của Nhãn dán

API công khai, giống như kim cương, là mãi mãi. Bạn có một cơ hội để làm cho đúng, vì vậy hãy cố gắng hết sức.

Để biết thêm chi tiết về điều đó, tác giả giới thiệu đến độc giả bài thuyết trình phiên hội thảo của mình, "Cách thiết kế API tốt và tại sao nó có vấn đề" . Slide Tại sao Thiết kế API quan trọng đối với Bạn nói rõ rằng điều này có liên quan đến bất kỳ hoạt động lập trình nào (hệ điều hành hay không, không quan trọng đối với tác giả):

• Nếu bạn lập trình, bạn là một nhà thiết kế API

  • Mã tốt là mô-đun - mỗi mô-đun có một API

• Các mô-đun hữu ích có xu hướng được sử dụng lại

  • Khi mô-đun có người dùng, không thể thay đổi API theo ý muốn
  • Các mô-đun tái sử dụng tốt là tài sản của công ty

• Suy nghĩ về các API cải thiện chất lượng mã

Kết luận slide cũng nhấn mạnh đây là một cách tiếp cận chung:

• Thiết kế API là một nghề cao quý và bổ ích

  • Cải thiện rất nhiều lập trình viên, người dùng cuối, công ty ...

API luôn thay đổi, nếu không thì điểm nâng cấp hệ thống là gì? Chỉ thay đổi nội bộ?

Mỗi phiên bản của hệ thống mang lại các API mới, các API cũ trở thành các API lỗi thời và lỗi thời biến mất.

Thay đổi API chỉ phải rất cẩn thận cả về mặt kỹ thuật và về mặt truyền thông.

Ý kiến ​​của tôi sẽ là một khi được phát hành, 'phiên bản' API đó là mãi mãi, nhưng bạn có thể loại bỏ nó bằng cách phát hành API '2.0' (có một số ví dụ về điều này đang xảy ra - hiện tại, tôi có thể nghĩ về Strava đã phát hành phiên bản 2.0 của API để phát triển nhằm tiêu thụ dịch vụ của họ).

Vấn đề là hỗ trợ quảng cáo API ban đầu đó ... Tôi đoán nó phụ thuộc vào việc sử dụng API cũ và giá trị của những người tiêu dùng API đó giữ cho bạn.

Quay trở lại 'ngày xưa' của Windows 3.x và 9x, v.v., một khi được phát hành, các API hệ điều hành đó đã được thực hiện và thiết lập. Bây giờ, các bản cập nhật hệ điều hành được đẩy lên mọi lúc, vì vậy các API mới có thể được phát hành, nhưng tôi nghĩ chừng nào bạn còn chạy một hương vị HĐH cụ thể (bản phát hành chính), những API đó sẽ chỉ được thêm vào, không bao giờ bị xóa ... là trường hợp cho bản phát hành chính 'tiếp theo'.

Hmm, có lẽ tôi đi lạc từ ý định câu hỏi ban đầu.

Nó phụ thuộc vào loại API (và tôi giả sử phá vỡ các thay đổi, nếu không thì tuyên bố rõ ràng là không đúng).

Nếu người gọi có thể chọn phiên bản họ đang sử dụng (ví dụ: với các thư viện / khung được gói cùng với ứng dụng gọi điện), thì việc thay đổi API không phải là vấn đề lớn - nhưng vẫn không tốt cho danh tiếng của phần mềm. Mọi người thích nâng cấp liền mạch.

Mặt khác, khi mọi người không thể tiếp tục sử dụng phiên bản API cũ (chẳng hạn như với dịch vụ trực tuyến hoặc những thứ như trình duyệt hoặc HĐH chạy phiên bản cũ là rất không mong muốn), thì việc thay đổi API theo cách không tương thích là rất tệ. thật vậy, vì nó sẽ phá vỡ tất cả các phần mềm sử dụng nó và cũng không được cập nhật. Điều này áp đặt chi phí bảo trì cho các nhà phát triển và họ sẽ ghét bạn vì điều đó. Và phần mềm không được bảo trì và phá vỡ cũng sẽ phản ánh xấu về bạn.

Về mặt hấp dẫn, có ít nhất một nhà cung cấp API liên tục đưa ra các thay đổi đột phá trong API và dù sao cũng thành công một cách lố bịch: Facebook. Nhưng họ quản lý các thay đổi rất cẩn thận: có một chính sách được công bố , các thay đổi vi phạm được công bố và giải thích trước ít nhất 90 ngày và các nhà phát triển có thể chọn kích hoạt chúng sớm trong khung thời gian đó.

Nếu bạn có tầm nhìn xa để bao gồm số phiên bản trong chính API. Hoặc trong cuộc gọi kết nối / khởi tạo hoặc ở đâu đó gần đầu danh sách tham số trên mỗi cuộc gọi, thì API của bạn có thể phát triển và biến đổi theo thời gian mà không làm gián đoạn các máy khách hiện có.

Mặc dù tất cả những gì chúng tôi làm là làm cho họ trở nên tốt nhất trong một lần, nhưng kể từ khi thay đổi và cải thiện thời gian, đôi khi chúng tôi cần cập nhật thông tin, như nhiều nhà cung cấp khổng lồ đã làm, (như cập nhật nhiều cuốn sách, twitter một chính chuyển sang oAuth và một vài chuyên ngành, nhưng nhiều khả năng tất cả đều đi kèm với sự cải thiện nên không có thay đổi thường xuyên. Và vâng, xin đừng ngừng hỗ trợ người lớn tuổi, thật đau !!

Bất cứ khi nào bạn phát hành bất kỳ loại giao thức truyền thông nào, rõ ràng sẽ bao gồm API, bạn có một cơ hội để hiểu đúng theo nghĩa là giao thức / giao diện phải tương thích ngược và có thể mở rộng.

Điều này cho phép bạn thêm chức năng mới và phát hành phiên bản mới mà không phải lo lắng về việc phá vỡ những người đang sử dụng phiên bản cũ hơn. Không bao giờ trong thế giới phần mềm, bạn sẽ gặp phải tình huống bạn có thể có một sự cắt giảm cứng tại một thời điểm nhất định và mọi người bỏ phiên bản cũ và bắt đầu sử dụng phiên bản mới.