Tại sao quy ước nói tên bảng DB phải là số ít nhưng tài nguyên RESTful số nhiều?

Đó là một quy ước khá thành lập rằng ít nhất các tên bảng cơ sở dữ liệu, trong SQL, phải là số ít. SELECT * FROM user;Xem câu hỏi và thảo luận này .

Đây cũng là một quy ước khá thành lập rằng các tên tài nguyên API RESTful phải ở dạng số nhiều. GET /users/123và POST /usersXem này .

Trong API được hỗ trợ cơ sở dữ liệu đơn giản nhất, tên của tài nguyên trong URL sẽ là bảng và các thành phần dữ liệu trong URL và các cơ quan yêu cầu / phản hồi sẽ ánh xạ trực tiếp đến các cột trong DB. Về mặt khái niệm, tôi không thấy sự khác biệt giữa hoạt động trên dữ liệu thông qua API lý thuyết này so với hoạt động trực tiếp trên dữ liệu thông qua SQL. Và do đó, sự khác biệt trong quy ước đặt tên giữa uservà userskhông có ý nghĩa với tôi.

Làm thế nào có thể biện minh cho sự khác biệt về số nhiều khi về mặt khái niệm, API REST và SQL đang làm điều tương tự?

Thông số REST (bất kỳ mức nào bạn muốn đi cùng) không được thiết kế dưới dạng truy cập cơ sở dữ liệu. Nó đang cố gắng mang tiêu chuẩn hóa để truy cập API. Các quy ước SQL được đề cập (dù bạn có muốn sử dụng chúng hay không) không được thiết kế với mục đích truy cập API. Chúng là để viết các truy vấn SQL.

Vì vậy, vấn đề cần giải nén ở đây là sự hiểu biết khái niệm rằng một API ánh xạ trực tiếp đến cơ sở dữ liệu. Chúng ta có thể tìm thấy điều này được mô tả như là một mô hình chống ít nhất là từ năm 2009 đến nay .

Lý do chính này là xấu? Mã mô tả "hoạt động này ảnh hưởng đến dữ liệu của tôi như thế nào?" trở thành mã máy khách .

Điều này có một số hiệu ứng khá khủng khiếp trên API. (không phải là một danh sách đầy đủ)

Nó làm cho việc tích hợp với API trở nên khó khăn

Tôi tưởng tượng các bước để tạo một người dùng mới được ghi lại như sau:

1. POST /users { .. }
2. POST /usersettings { .. } với một số giá trị mặc định
3. POST /confirmemails { .. }

Nhưng làm thế nào để bạn xử lý một thất bại của bước # 2? Đã bao nhiêu lần việc xử lý sao chép logic tương tự này cho các khách hàng khác của API của bạn?

Các hoạt động dữ liệu này thường dễ dàng hơn để sắp xếp theo phía máy chủ, trong khi được bắt đầu từ máy khách dưới dạng một hoạt động. Ví dụ POST /newusersetup. Các DBA có thể nhận ra đây là một thủ tục được lưu trữ, nhưng hoạt động API có thể có các hiệu ứng vượt ra ngoài cơ sở dữ liệu.

Bảo mật API trở thành một lỗ đen tuyệt vọng

Giả sử bạn cần hợp nhất hai tài khoản người dùng.

1. GET /users/1
2. PUT /users/2 { .. }
3. DELETE /users/1

Làm thế nào bạn sẽ thiết lập quyền người dùng để cho phép tính năng hợp nhất trong khi không cho phép xóa người dùng? Là xóa một người dùng thậm chí khá đại diện bởi DELETE /users/1khi nào /usersettingscũng tồn tại?

Các hoạt động API nên được xem là các hoạt động cấp cao hơn (cơ sở dữ liệu) có thể gây ra nhiều thay đổi trong hệ thống.

Bảo trì trở nên khó khăn hơn

... bởi vì khách hàng của bạn phụ thuộc vào cấu trúc cơ sở dữ liệu của bạn.

Dựa trên kinh nghiệm của tôi với kịch bản này:

• Bạn không thể đổi tên hoặc xóa bảng / cột hiện có. Ngay cả khi chúng được đặt tên không chính xác cho chức năng của chúng hoặc không còn được sử dụng. Khách hàng sẽ phá vỡ.
• Các tính năng mới không thể thay đổi cấu trúc dữ liệu hiện có, vì vậy dữ liệu và chức năng của nó thường được tách biệt một cách giả tạo ngay cả khi nó hoàn toàn thuộc về một tính năng hiện có.
• Cơ sở mã dần dần trở nên khó hiểu hơn do sự phân mảnh, tên khó hiểu và hành lý còn sót lại không thể được gỡ bỏ một cách an toàn.
• Tất cả trừ những thay đổi tầm thường ngày càng trở nên rủi ro và tốn thời gian.
• Hệ thống đình trệ và cuối cùng được thay thế.

Đừng để lộ cấu trúc cơ sở dữ liệu của bạn trực tiếp cho khách hàng ... đặc biệt là các khách hàng mà bạn không có quyền kiểm soát phát triển. Sử dụng API để thu hẹp ứng dụng khách xuống chỉ hoạt động hợp lệ.

Vì vậy, nếu bạn đang sử dụng API như một giao diện đi thẳng vào cơ sở dữ liệu, thì số nhiều là điều bạn lo lắng nhất. Đối với các thử nghiệm khác, tôi khuyên bạn nên dành thời gian để xác định các hoạt động cấp cao hơn mà API sẽ thể hiện. Và khi bạn nhìn theo cách đó, không có xung đột giữa tên thực thể API số nhiều và tên thực thể SQL số ​​ít. Họ ở đó vì những lý do khác nhau.

API REST và SQL KHÔNG "làm điều tương tự"

OP yêu cầu:

Làm thế nào có thể biện minh cho sự khác biệt về số nhiều khi về mặt khái niệm, API REST và SQL đang làm điều tương tự?

À, nhưng châu chấu, có vẻ như giao diện RESTful và các bảng SQL "đang làm điều tương tự", nhưng vệ sinh lập trình tốt cho chúng ta biết rằng luôn có một lớp trung gian làm trung gian giữa API REST và cơ sở dữ liệu. Bỏ qua điểm này là đi lạc từ con đường đến giác ngộ phần mềm! :)

Vì vậy, các API RESTful và các bảng SQL có thể vui vẻ tuân theo các quy ước đặt tên thành ngữ của riêng chúng, được ghi chép lại và thảo luận kỹ lưỡng ở nơi khác.