Làm thế nào để mô tả một sự thay đổi kiến ​​trúc cố ý phá vỡ các tiêu chuẩn REST?

Tôi đang đề xuất các thay đổi đối với một dự án phần mềm được kiến ​​trúc rất kém, chịu vô số vấn đề. Ở mức cao, dự án sử dụng Angular ở mặt trước và tiêu thụ nhiều API REST khác nhau; đó là tất cả tuyệt vời (tôi không thấy sự cần thiết phải thay đổi công nghệ hoặc công cụ của chúng tôi). Vấn đề là cơ sở mã lớn hơn trong giao diện người dùng so với API phía máy chủ. Phần lớn logic nghiệp vụ nằm trong UI, với API REST là các giao diện cơ sở dữ liệu CRUD đơn giản cho lớp UI.

Ví dụ: POST cho khách hàng sẽ tạo một hồ sơ khách hàng, trong khi PUT sẽ sửa đổi khách hàng đó. Không nhiều hơn, và không ít hơn nhiều. Tuy nhiên logic kinh doanh của chúng tôi đòi hỏi nhiều hơn thế. Quá trình chung tạo khách hàng thực hiện khá nhiều hơn là chèn 1 bản ghi cơ sở dữ liệu. Nó sẽ cung cấp dữ liệu trong các bảng cần thiết khác, thực hiện các xác nhận và tính toán nhất định, v.v. Tôi muốn thực hiện một cuộc gọi POST / PUT duy nhất gói gọn tất cả các hành vi này, làm giảm tải của khách hàng tiêu thụ.

Vì vậy, quan điểm của tôi là sự phối hợp bao trùm này sẽ sống trên máy chủ (nơi chúng tôi có toàn quyền kiểm soát, nhật ký, v.v.), chứ không phải UI, nhưng một điều ngược lại là cách tiếp cận này sẽ không còn RESTful. Vì vậy, tôi không chắc làm thế nào để mô tả tốt nhất cách tiếp cận này khi đề xuất của tôi là tiếp tục với ngăn xếp công nghệ hiện có, nhưng thực hiện các thay đổi cơ bản ở các vị trí có mã.

Tôi không chắc làm thế nào để mô tả tốt nhất cách tiếp cận này khi đề xuất của tôi là tiếp tục với ngăn xếp công nghệ hiện có, nhưng thực hiện các thay đổi cơ bản ở các vị trí có mã.

Service oriented architecture.

Bạn đang đề xuất thiết kế lại hệ thống của bạn để các quy tắc kinh doanh và dữ liệu của bạn ở cùng một nơi. Đó thực sự là định nghĩa của một dịch vụ ; xem bài nói chuyện của Udi Dahan về Tìm kiếm ranh giới dịch vụ .

Thanh bên: như Eric đã lưu ý, điều này không liên quan gì đến "REST". Hoàn toàn không có lý do gì mà bạn không thể đặt API REST (nghĩa là API đáp ứng các ràng buộc của kiểu kiến ​​trúc REST ) trước dịch vụ của bạn. Nhưng điều đó có thể không rõ ràng đối với những người hiểu REST có nghĩa là ánh xạ các hoạt động cơ sở dữ liệu sang các phương thức HTTP.

Nó có thể, hoặc có thể, không đáng để đầu tư vào việc thay đổi sự hiểu biết của khán giả về REST.

REST không phải là CRUD. "Phản biện" đó dựa trên sự hiểu biết cơ bản thiếu sót về REST là gì. Tôi chưa thấy bất cứ điều gì trong bài viết của bạn cho thấy sự thay đổi của bạn sẽ khiến API của bạn trở nên ít hơn RESTful.

Một điều nữa cần ghi nhớ là như sau ... Không xác thực phía máy chủ quy tắc kinh doanh của bạn, có nghĩa là bạn hoàn toàn tin tưởng bất cứ điều gì xuất hiện, thông qua yêu cầu POST, là hợp lệ.

Có nghĩa là, ví dụ, trong khi ứng dụng góc cạnh của bạn có thể kiểm tra xem khách hàng có độ tuổi hợp lệ hay không và đảm bảo rằng người dùng hợp pháp nhận được phản hồi chính xác, bất kỳ ai biết url đến api của bạn đều có thể thực hiện yêu cầu POST có chứa một số giá trị không hợp pháp không còn được xác nhận

Vì vậy, đề xuất của tôi sẽ là chuyển các quy tắc kinh doanh của bạn sang API, để nó xác thực đầu vào và trả về các lỗi thích hợp (hoặc có lẽ chỉ là các mã chỉ ra lỗi sai) trong phần nội dung của phản hồi. Các mã này có thể được sử dụng bởi ứng dụng front-end của bạn để chỉ ra lỗi sai.

Để thêm vào các câu trả lời tốt khác ở đây:

Giao diện của bạn, REST hoặc cách khác, không nên bị hạn chế dựa trên một số loại giả định xung quanh chi tiết triển khai. Điều này hoàn toàn phản đối với khái niệm dịch vụ là một lớp trừu tượng.

Một trong những lợi ích chính khi sử dụng dịch vụ là chi tiết triển khai có thể được thay đổi mà không cần khách hàng phải làm gì cả. Từ những gì bạn đã mô tả, có vẻ như không có lớp trừu tượng thực sự. Các chi tiết của việc thực hiện đã được đưa ra thông qua HTTP. Không có gì về REST nói rằng điều đó là cần thiết, hữu ích hoặc mong muốn. Trong thực tế, tôi nghĩ rằng tôi có thể tranh luận một số phần nhất định của định nghĩa REST có nghĩa là trên thực tế, đây là một triển khai phi RESTful.

Những gì bạn đang đề xuất là làm thế nào một lớp dịch vụ thích hợp nên được thiết kế. Nếu ai đó nói với bạn rằng bạn không thể làm điều đó bởi vì đó không phải là RESTful, điều đó thật đáng tiếc. Bạn có thể yên tâm rằng ai đó nói với bạn rằng ít biết gì về REST.

Dựa trên câu hỏi của bạn, bạn có một tài nguyên được gọi là khách hàng. Bất cứ điều gì và mọi thứ cần thiết để tạo tài nguyên khách hàng hợp lệ đều có thể và nên được xử lý trong POSTtài nguyên cơ sở khách hàng (hoặc thay thế / tùy chọn trong PUT cho tài nguyên khách hàng cụ thể, nếu không tồn tại.) REST không nói gì về số lượng bản ghi cơ sở dữ liệu bạn cần tạo trên một cuộc gọi nhất định. Như Colin Young đã nhận xét, hoàn toàn không cần phải có một cơ sở dữ liệu, hoàn toàn không liên quan đến cách các dịch vụ được triển khai từ góc độ REST.

Có một số câu trả lời hay ở đây, nhưng tôi không chắc rằng chúng sẽ giúp bạn thuyết phục đồng nghiệp. Như nhiều người đã chỉ ra, những gì bạn đang đề xuất không phải là một sự thay đổi so với thiết kế RESTful và tôi nghĩ đó là chìa khóa để đưa họ lên tàu với đề xuất của bạn.

REST không đảm bảo API của bạn chỉ cho phép lưu trữ và truy xuất dữ liệu. Thay vào đó, nó quan tâm đến việc mô hình hóa các hành động như tài nguyên. API của bạn sẽ cho phép các hành động được thực hiện (rốt cuộc đó là Giao diện lập trình ứng dụng ). Câu hỏi là làm thế nào để mô hình hóa những hành động đó.

Thay vì đưa ra một thuật ngữ, các ví dụ có lẽ là cách tốt nhất để giải thích điều này với đồng nghiệp của bạn . Bằng cách này, bạn có thể cho thấy hiện tại họ đang làm gì, vấn đề này gây ra vấn đề gì, giải pháp giải quyết vấn đề và làm thế nào nó vẫn còn RESTful.

Hãy nhìn vào đối tượng khách hàng của bạn.

Vấn đề:

Giao diện người dùng gửi một khách hàng, nhưng các bảng tiếp theo chưa được cập nhật. Điều gì xảy ra nếu một trong những cuộc gọi tiếp theo không thành công do lỗi trong mã UI của bạn (hoặc trình duyệt trình duyệt sai, v.v.)? Bây giờ dữ liệu của bạn đang ở trong một trạng thái không nhất quán. Nó thậm chí có thể là một trạng thái phá vỡ các phần khác của API hoặc UI của bạn, chưa kể rằng nó đơn giản là không hợp lệ. Làm thế nào để bạn phục hồi? Bạn sẽ phải kiểm tra mọi trạng thái có thể để chắc chắn điều này sẽ không phá vỡ thứ gì đó, nhưng sẽ rất khó để biết điều gì có thể xảy ra.

Dung dịch:

Tạo một điểm cuối API để tạo khách hàng. Bạn biết rằng bạn không muốn có điểm cuối "/ khách hàng / tạo" hoặc thậm chí "/ tạo-khách hàng", bởi vì tạo là một động từ và sẽ vi phạm REST. Vì vậy, danh từ đó. "/ Tạo khách hàng" có thể làm việc. Bây giờ khi bạn POST đối tượng CustomerCreation của mình, nó sẽ gửi tất cả các trường cần thiết cho một khách hàng được tạo hoàn toàn. Điểm cuối sẽ đảm bảo rằng dữ liệu hoàn chỉnh và hợp lệ (ví dụ trả về 400 hoặc thứ gì đó nếu không xác thực) và có thể duy trì tất cả trong một giao dịch db, chẳng hạn.

Nếu bạn cũng cần một điểm cuối để NHẬN / đối tượng khách hàng, điều đó tốt. Bạn có thể có cả hai. Bí quyết là tạo ra các điểm cuối phục vụ nhu cầu của người tiêu dùng.

Ưu điểm:

1. Bạn đảm bảo rằng bạn sẽ không kết thúc với trạng thái xấu
2. Nó thực sự dễ dàng hơn trên các nhà phát triển UI nếu họ không phải "biết" việc đặt hàng các yêu cầu, mối quan tâm xác nhận, v.v.
3. Đây không phải là trò chuyện của API, giảm độ trễ của yêu cầu mạng
4. Việc kiểm tra và khái niệm hóa các kịch bản dễ dàng hơn (các phần dữ liệu bị thiếu / không đúng định dạng từ giao diện người dùng không lan truyền trong các yêu cầu, một số trong đó có thể thất bại)
5. Nó cho phép đóng gói logic kinh doanh tốt hơn
6. Nói chung làm cho bảo mật dễ dàng hơn (vì logic kinh doanh và phối hợp trong UI có thể được sửa đổi bởi người dùng)
7. Sẽ có khả năng giảm trùng lặp logic (nhiều khả năng bạn sẽ có hơn 2 người tiêu dùng API hơn 2+ API cung cấp quyền truy cập vào cùng một dữ liệu)
8. Vẫn 100% RESTful

Nhược điểm:

1. Nó có khả năng làm việc nhiều hơn cho nhà phát triển phụ trợ (nhưng có thể không hoạt động lâu dài)

Mọi người có thể khó hiểu được mô hình này và điều gì tốt cho nó nếu họ chưa thử. Hy vọng bạn có thể giúp họ nhìn thấy bằng cách sử dụng một ví dụ từ mã của riêng bạn.

Kinh nghiệm của riêng tôi là một khi các nhà phát triển trong nhóm của tôi bắt đầu thực hiện chiến lược này, họ gần như ngay lập tức thấy được lợi ích.

Học cao hơn:

Bài viết này từ thinkworks thực sự đã giúp tôi có được ý tưởng mô hình hóa các hành động như các đối tượng bằng cách sử dụng các ví dụ thực tế: https : // www. Dùtworks.com/insights/blog/rest-api-design-resource-modeling

Tôi cũng đề nghị đọc lên CQRS và Tìm nguồn sự kiện vì họ quan tâm chính xác đến loại điều này (tức là tách API của bạn khỏi logic kiên trì thực tế). Tôi không biết đồng nghiệp của bạn sẽ sẵn lòng đọc loại tin này như thế nào, nhưng nó có thể giúp bạn rõ ràng hơn và giúp bạn giải thích cho họ.