Chạy API, nếu tôi sửa tiêu đề kiểu nội dung sẽ phá vỡ mọi thứ cho khách hàng?

Chúng tôi đang chạy một API với khá nhiều người sử dụng nó. Do một số vụng về di sản từ phía tôi, một trong những điểm cuối đang trả lại tiêu đề loại nội dung sai , jskhi cần json. Câu hỏi của tôi là, nếu chúng ta sửa lỗi này bằng cách hoán đổi để trả về giá trị chính xác, làm thế nào nó có thể gây rối cho mọi khách hàng hiện tại của chúng ta? Hay nói cách khác, bạn có mong đợi nhiều thư viện máy khách HTTP khác nhau sẽ gặp phải các lỗi nghiêm trọng khi thấy một sự thay đổi như vậy không?

Chúng tôi đang cố gắng quyết định xem đây có phải là một thay đổi mà chúng tôi có thể tiến hành và thực hiện mà không đổ mồ hôi quá nhiều hay không, hoặc chúng tôi nên gửi email cẩn thận cho tất cả người dùng và thông báo thời gian khấu hao trong nhiều năm ... hoặc một cái gì đó ở giữa.

Có lẽ nó phụ thuộc một chút vào loại máy khách HTTP khác nhau đang được sử dụng, vì vậy tôi đã xem xét các tác nhân người dùng. Trả lời: rất nhiều cái khác nhau! Đây là một số trong những người hàng đầu:

"okhttp / 3.2.0", "python-request / 2.10.0", "Ruby", "python-request / 2.7.0", "Mozilla / 5.0", "Java / 1.8.0_91", "python-request /2.4.3 "," okhttp / 3.3.0 "," Lucee "," Dalvik / 2.1.0 "," Google-HTTP-Java-Client / 1.21.0 "," PHP_appname "," Nativehost "," Java /1.7.0_67 "," Apache-HttpClient / UNAVAILABLE "," Dalvik / 1.6.0 "," Web-sniffer / 1.1.0 "," unirest-objc / 1.1 "

Thư viện ngôn ngữ phía máy chủ và máy chủ khác nhau. Chủ yếu không phải là trình duyệt chạy javascript, nhưng một số trong số đó cũng vậy.

Hầu hết mọi người dường như không nhận thấy rằng loại nội dung là sai, nhưng thỉnh thoảng một yêu cầu hỗ trợ mới lại xuất hiện phàn nàn về vấn đề này, vì vậy chúng tôi muốn khắc phục nó.

Làm thế nào xấu nó có thể gây rối mọi thứ cho khách hàng hiện tại của chúng tôi?

Nó hoàn toàn có thể đánh chìm tàu ​​chiến của họ nếu họ đã viết mã dựa trên Loại Nội dung này không chính xác.

Tôi sẽ không mong đợi các thư viện ném lỗi, nhưng tôi hy vọng rằng trong một số trường hợp, các thư viện nghiêm ngặt đã có hành vi bị ghi đè để xử lý loại MIME không chính xác.

Nếu API của bạn có giá trị phiên bản / sửa đổi trong trường yêu cầu ở đâu đó, hãy nâng nó lên và trong phiên bản mới trả về loại chính xác nhưng tiếp tục trả về loại không chính xác trong các phiên bản cũ hơn. Nếu bạn không có trường yêu cầu như vậy, bây giờ là thời điểm tốt để thêm.

Bạn có mong đợi nhiều thư viện máy khách HTTP khác nhau sẽ đưa ra các lỗi nghiêm trọng khi thấy một sự thay đổi như vậy không?

Không. Mọi thư viện máy khách HTTP mà tôi quen thuộc sẽ bỏ qua tiêu đề loại nội dung trừ khi lập trình viên đọc cụ thể tiêu đề đó và làm gì đó với nó. Tôi có thể tưởng tượng một thư viện trong đó kiểu nội dung: application / json tự động khiến trình phân tích cú pháp json tham gia nhưng tôi không biết bất kỳ trường hợp nào thực sự xảy ra.

Hầu hết mọi người dường như không nhận thấy rằng loại nội dung là sai, nhưng thỉnh thoảng một yêu cầu hỗ trợ mới lại xuất hiện phàn nàn về vấn đề này, vì vậy chúng tôi muốn khắc phục nó.

Làm thế nào mà họ nhận thấy tiêu đề không chính xác? Có thể đáng để xem xét điều đó, bởi vì nếu tiêu đề không chính xác thực sự gây ra sự cố cho họ thì rõ ràng họ không bỏ qua nó và họ có thể gặp vấn đề nếu nó được sửa.

Quá khó để nói mà không nhận được đăng nhập từ tất cả các khách hàng của bạn. Tôi sẽ đề nghị thực hiện một trong hai cách tiếp cận sau để nâng cấp API của bạn lên v.Next.

1. Mở rộng API hiện có. Thêm một chuỗi truy vấn hoặc một số biến khác vào API của bạn có nghĩa là sử dụng v.Next. Đối với tất cả các yêu cầu sử dụng biến đó, hãy sử dụng loại nội dung được cập nhật.
2. Chạy một phiên bản Staging hoặc Pre-Production của API của bạn song song với API hiện tại của bạn. Nó phải gần giống với sản xuất. Ngay cả khi sử dụng cùng một back-end. Mặc dù điều này sẽ có những thay đổi được đề xuất cho v.Next.

Trong cả hai trường hợp, hãy liên lạc với khách hàng của bạn về những thay đổi bạn muốn thực hiện và ngày / giờ cắt mục tiêu. Khuyến khích họ kiểm tra tốt trước ngày mục tiêu để đảm bảo không có sự gián đoạn dịch vụ.

Đảm bảo bạn có một trang dành riêng chi tiết các thay đổi được thực hiện cho v.Next. Điều này nên được bao gồm trong các thông tin liên lạc gửi đến khách hàng của bạn. Nếu bạn đã thảo luận về bất kỳ bản sửa lỗi nào với các khách hàng hiện tại, hãy bao gồm các bản sửa lỗi trên trang này.

Cuối cùng, bước qua ranh giới giữa giao tiếp quá mức với khách hàng của bạn và spam họ. Những thông báo này có thể dễ dàng bị bỏ qua khi có nhiều ưu tiên cấp bách / khẩn cấp hơn xuất hiện.

FWIW, nếu mọi thứ đang hoạt động tôi sẽ không lo lắng quá nhiều về nó. Nếu ví dụ bạn thấy rằng điều này gây ra lỗ hổng bảo mật đáng kể thì đó sẽ là một lý do tuyệt vời để loại bỏ sự thay đổi này. Nếu không, tôi sẽ chờ đợi một cái gì đó cấp bách hơn để bao gồm thay đổi này.

Đây là một ví dụ về một thư viện (tốt, một lệnh) mà điều này sẽ phá vỡ:

Các PowerShell cmdlet Invoke-RestMethodhoạt động khác nhau với JSON. Nếu kết quả của yêu cầu là JSON, XML hoặc ATOM / RSS (và tôi nghĩ rằng nó dựa trên tiêu đề), thì nó sẽ phân tích / giải tuần tự hóa nó và trả về các đối tượng gốc, nếu không nó sẽ trả về dữ liệu thô.

Vì vậy, mã hiện tại sẽ được viết để xử lý một chuỗi (có lẽ bằng cách chuyển nó tới ConvertFrom-Json) và tất cả sẽ bắt đầu thất bại.

Tôi đã nhận thấy hai hậu quả:

1. Một số thư viện khách hàng sẽ không xử lý phản hồi đúng cách. Ví dụ, phản hồi trả về một chuỗi thay vì json hoặc một mảng.
2. Nén không phải lúc nào cũng được áp dụng.