Tôi đang làm việc trên một dự án ứng dụng iOS mới, về phía di động. Một số thay đổi kiến trúc đang diễn ra và hóa ra chúng ta sẽ phải dựa vào API riêng được xây dựng tùy chỉnh sẽ được sử dụng bởi ứng dụng chúng ta đang xây dựng và cả các khách hàng khác như trang web.
API đang được thiết kế tuân theo kiểu Phần còn lại của các hoạt động URI và CRUD tập trung vào tài nguyên được ánh xạ tới các động từ HTTP. những thứ như:
GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793
Vấn đề là phong cách này thường dẫn đến nhu cầu máy khách di động thực hiện nhiều yêu cầu tải một màn hình ứng dụng hoặc quản lý một hành động UI người dùng. Điều này dẫn đến ứng dụng ở chế độ tải trong 8 giây cho đến khi ứng dụng có mọi thứ cần thiết. Một ứng dụng chậm và không phản hồi.
Các máy khách di động có những hạn chế nghiêm trọng khi nói đến kết nối và lý tưởng nhất là chúng ta nên tuân theo quy tắc đó:
1 màn hình == 1 cuộc gọi API
1 lưu == 1 lệnh gọi API.
Có nhiều tình huống trong đó điều này đặt bạn vào một khóa học xung đột với các nguyên tắc thiết kế REST, ví dụ:
- giả sử ứng dụng của bạn đã ngoại tuyến trong một ngày và bạn cần đồng bộ hóa với bốn bảng cơ sở dữ liệu phụ trợ và bạn cần một cuộc gọi như
www.example.com/sync_everything?since=2015-07-24 - giả sử có một màn hình nơi người dùng có thể chỉnh sửa nhiều đối tượng của mình, ví dụ đánh dấu các tác vụ trong danh sách việc cần làm của mình. cần có một cách để chỉnh sửa tất cả các bản ghi tác vụ đó trong một lệnh gọi API hàng loạt thay vì một lệnh gọi API cho mỗi lần chỉnh sửa.
- giả sử có một màn hình trộn thông tin từ các bảng db ĐẶT HÀNG, SALESMEN và SẢN PHẨM, tôi sẽ nhận được dữ liệu đó trong một cuộc gọi thay vì ba.
rủi ro là chúng ta có thể kết thúc với API yên tĩnh nhất và cũng có ứng dụng di động không phản hồi vô dụng nhất hiện có.
Vấn đề là tôi chỉ là một nhà thầu mới ở đó và những gì tôi cần là thứ giúp tôi đưa ra những quan điểm đó, một số bài viết từ các nguồn được tôn trọng hoặc một cái gì đó tương tự. Những người chơi chính thỏa hiệp với kiểu REST cho ứng dụng khách di động của họ (ví dụ: bằng cách sử dụng điểm cuối API tổng hợp).
Hoặc bất kỳ giải pháp cho vấn đề chung này. Cảm ơn!