Bối cảnh

Do tính phi trạng thái của kiểu kiến ​​trúc REST liên quan đến việc mỗi yêu cầu đứng hoàn toàn một mình, máy chủ hàng đầu không bao giờ lưu trữ bất kỳ thông tin nào về máy khách.

Do đó, kiểm soát đồng thời bi quan không phù hợp bởi vì nó sẽ yêu cầu máy chủ lưu trữ máy khách nào có khóa trên tài nguyên. Kiểm soát đồng thời lạc quan sau đó được sử dụng, với sự trợ giúp của Etagtiêu đề. (btw, như tôi đã hỏi ở đó /programming/30080634/concurrency-in-a-rest-api )

Vấn đề

Vấn đề chính với cơ chế kiểm soát đồng thời lạc quan là bạn cho phép mọi lúc, mọi khách hàng, thực hiện bất kỳ hoạt động nào.

Và tôi muốn tránh điều đó mà không phá vỡ nguyên tắc không quốc tịch của REST. Tôi có nghĩa là tất cả các khách hàng không thể thực hiện bất kỳ hoạt động bất cứ lúc nào.

Câu hỏi

Trong tâm trí của tôi, nó có thể với một cơ chế kiểm soát tương tranh bán lạc quan , như thế:

• Khách hàng có thể yêu cầu mã thông báo
• Chỉ một mã thông báo có thể được tạo và có thời hạn hiệu lực hạn chế
• Để thực hiện các hoạt động trên các tài nguyên (như POST hoặc PUT ), khách hàng phải cung cấp mã thông báo này như một phần của phần thân (hoặc tiêu đề?) Của yêu cầu. Khách hàng không có mã thông báo không thể thực hiện các hoạt động này.

Nó rất giống với điều khiển đồng thời lạc quan, ngoại trừ việc chỉ có một khách hàng có thể thực hiện một số thao tác (một hoạt động có mã thông báo) ... ngược lại với "tất cả các khách hàng có thể thực hiện tất cả các hoạt động".

Cơ chế này có tương thích với phong cách kiến ​​trúc REST không? Liệu nó có phá vỡ bất kỳ ràng buộc của nó? Tôi đã suy nghĩ để hỏi về SO, nhưng đây có vẻ là một câu hỏi cấp cao hơn, liên quan đến thiết kế phần mềm.

Bạn không bao giờ nên (như chưa bao giờ EVER) khóa bất kỳ tài nguyên nào trong khi chờ tương tác của người dùng.

Tại một số điểm, một số người dùng của bạn sẽ cất cánh trong một ngày cuối tuần dài để lại một số hồ sơ quan trọng bị khóa.

À nhưng bạn sẽ không để điều đó xảy ra vì bạn có sơ đồ giải quyết hết thời gian / bế tắc thông minh; sau đó, tại một thời điểm nào đó, điều này sẽ trở nên sai lầm khủng khiếp và một người dùng nhận được thông báo "tiện ích của bạn đã được yêu cầu" sẽ được hét lên tại bàn trợ giúp để biết lý do tại sao tiện ích của anh ta không được gửi.

Hầu hết mọi người có thể đối phó với thông báo "xin lỗi người dùng khác vừa đặt hàng phần này".

Sử dụng mã thông báo rất phổ biến trong API, các mã thông báo này thường được gửi dưới dạng tiêu đề và có vòng đời rõ ràng. Hãy suy nghĩ ví dụ OAuth.

Bất kể ngôn ngữ lập trình hoặc khung của bạn, API REST đều tương tự nhau.

Tôi có thể nghĩ ra một số tình huống mà bạn muốn hạn chế đồng thời, hai trong số đó là:

1. Nhiều khách hàng cập nhật cùng một tài nguyên như một hàng cơ sở dữ liệu. Ví dụ: hai yêu cầu đồng thời, một yêu cầu xóa một bản ghi và một yêu cầu khác cố gắng cập nhật cùng một bản ghi. Tùy thuộc vào cơ sở dữ liệu của bạn và cách bạn đã thiết lập nó, bạn có thể khóa các bản ghi hoặc hoạt động không hợp lệ vì dữ liệu sẽ khác nhau hoặc sẽ không tồn tại.

2. Một siêu người dùng hoặc quản trị viên thực hiện các hành động đặc biệt với API.

Làm gì trong những trường hợp này?

1. Sử dụng các giao dịch trong cơ sở dữ liệu, singletons, khóa và các cơ chế tương tự để đồng bộ hóa quyền truy cập vào tài nguyên.

2. Mã thông báo có thể hoạt động, tôi nghĩ sẽ tốt hơn nếu bạn không lưu trữ thông tin về khách hàng, chỉ về chính mã thông báo. Trên một bước, bạn có thể xác thực người dùng và gán mã thông báo. Sau đó, chỉ cần xác thực rằng mã thông báo còn sống và hợp lệ. Sử dụng mã thông báo có thể được giải mã để có thêm thông tin. Bạn có thể lưu trữ nếu đây là mã thông báo đặc biệt và chỉ cho phép bật tại một thời điểm. Bằng cách này, bạn xác thực mã thông báo, không phải người dùng.

Tôi hi vọng cái này giúp được.

REST một mình là quá nguyên thủy, thực sự. Bạn có thể bắt đầu với REST, nhưng cuối cùng, ứng dụng phong phú của bạn sẽ cần truy vấn với các phép nối và cập nhật với các giao dịch. Mỗi nhà phát triển cố gắng tự thêm những thứ này sẽ dễ bị lỗi và không nhất quán. May mắn thay, có một tiêu chuẩn mới nổi gọi là OData thực hiện điều đó. Nó xếp chồng lên trên REST và cung cấp (1) ngôn ngữ truy vấn cho phép các phép nối đơn giản sử dụng các thuộc tính điều hướng (mà không phải lộ các khóa ngoại) và, (2) xử lý hàng loạt bao gồm các bộ thay đổi nguyên tử.

Xem tại đây để (1) https://stackoverflow.com/a/3921423/471129 , và,

Xem tại đây và cho (2) https://stackoverflow.com/a/21939972/471129