Tôi đã cố gắng tìm kiếm và tìm kiếm trên khắp mọi nơi, nhưng không thể tìm thấy một cơ quan dứt khoát về chủ đề này. Trong khi là đúng với nguyên tắc REST, làm thế nào tôi nên thiết kế giao diện HTTP cho:Mẫu cấu trúc dữ liệu RESTful
Một lệnh danh sách (nhận, thêm, chèn vào vị trí, sắp xếp lại, loại bỏ)
Một tập (nhận được, thêm, xóa)
Một bảng băm (nhận được, thêm, xóa)
LƯU Ý: Các cấu trúc dữ liệu để chứa tham chiếu đến các nguồn lực hiện có với id biết
Đó là cách tôi sẽ làm điều đó cho một danh sách lệnh và bảng băm. Tôi đoán các phương pháp sẽ là như nhau cho một bộ và một danh sách:
Nhận item 123:
GET /list/123
Nối một mục vào danh sách:
POST /list/
Chèn mục mới vào vị trí 5:
POST /list/?position=5
Chuyển mục 123 vị trí 3:
PUT /list/123?position=3
Xóa item 123:
DELETE /list/123
Xóa mục ở vị trí 3:
DELETE /list/?position=3
Tất nhiên, API của bạn nên cập nhật các chỉ số của tất cả các yếu tố khi thực hiện chèn và xóa.
Get mục "somekey":
GET /hashtable/somekey
Thêm mục "somekey":
POST /hashtable/somekey
Hủy bỏ mục "somekey":
DELETE /hashtable/somekey
@ cha
Bạn không thể xác định giao diện như vậy trực tiếp.
Một lệnh danh sách (nhận, thêm, chèn vào vị trí, sắp xếp lại, loại bỏ)
Bằng cách loại bỏ "chèn vào vị trí" và "sắp xếp lại" bạn hoàn toàn có thể thực hiện "nhận được", "add" và "loại bỏ" ví dụ:
Đây là một ví dụ rất thô, mặc dù nó phác thảo một số ý tưởng. Để đạt được "sắp xếp lại" và "chèn vào vị trí", bạn cần phải thực hiện ngữ nghĩa hành động của riêng bạn mà bạn có thể bao gồm trong đại diện tài nguyên của bạn và cho khách hàng biết LÀM THẾ NÀO để thực hiện các hoạt động này. Để tham khảo, bạn có thể xem đề xuất đặc điểm kỹ thuật JSON PATCH này: https://tools.ietf.org/html/rfc6902 cố gắng mô tả các hoạt động đó.
Không nhất thiết phải sử dụng định dạng phương tiện hiện có, bạn có thể xác định định dạng phương tiện của mình theo không gian tên của riêng mình, ví dụ: application/vnd.your-company.format-name + json mô tả các khả năng này và cũng quảng cáo thông tin này khách hàng.
Bạn nên tách cơ chế truyền tải khỏi ứng dụng cơ bản. Tôi sẽ xem xét việc thiết kế ứng dụng một cách chính xác, sau đó tìm ra cách truy cập nó thông qua HTTP. Bằng cách này bạn có thể dễ dàng thêm hoặc thay đổi các cơ chế truyền tải (SOAP, SCA, vv) mà không ảnh hưởng đến ứng dụng cơ bản.
Khi bạn đã ứng dụng được thiết kế chính xác, hãy xem xét truy cập ứng dụng từ yêu cầu HTTP thông qua một cái gì đó giống như Bộ điều hợp hoặc Mẫu khách truy cập.
Đây là ý tưởng của tôi để sắp xếp lại.
Có phương thức HTTP được gọi là PATCH được sử dụng để cập nhật các đoạn của tài nguyên. Cung cấp cho tài nguyên của bạn một tài sản mới được gọi là index, sau đó thực hiện cuộc gọi với phương pháp PATCH
PATCH /collection
[
{
"id: "original index 0"
"index": 1
}
{
"id: "original index 1"
"index": 0
}
]
Sau đó máy chủ của bạn back-end cần phải tìm ra cách để làm điều này nguyên tử. Nhưng giao diện-khôn ngoan, tôi nghĩ rằng đây là cách tốt nhất để giữ đúng với RESTful.
Ngoài ra, có giải pháp tốt hơn, nhưng có thể không áp dụng cho trường hợp của mọi người. Kể từ khi đặt hàng luôn luôn phụ thuộc vào một số loại tiêu chí, nó thậm chí có thể đơn giản như thứ tự chèn. Hãy để url bộ sưu tập của bạn hỗ trợ chuỗi truy vấn orderBy và để điều này là orderBy quyết định cách kết quả được sắp xếp. Sau đó, trong khi sắp xếp lại cuộc gọi từ khách hàng, chỉ cần cập nhật thuộc tính của tài nguyên được sử dụng cho các tiêu chí đặt hàng.
Tôi đến câu hỏi này chủ yếu tìm kiếm một cách RESTful để sắp xếp lại. Tôi không thực sự thích bất kỳ câu trả lời nào, vì vậy đây là những gì tôi nghĩ là hầu hết là RESTful.
Đối với sắp xếp lại bạn có thể làm cho trật tự một nguồn lực:
/list/order
Sau đó, bạn có thể thực hiện các hoạt động bình thường vào nó (đối với các ví dụ này giả định một danh sách với 5 mặt hàng hiện đang ở trong đó):
"items":" [
{
"id": "A",
"name": "Monkey"
},
{
"id": "B",
"name": "Cow"
},
{
"id": "C",
"name": "Horse"
},
{
"id": "D",
"name": "Turkey"
},
{
"id": "E",
"name": "Tasmanian Devil"
},
]
Lưu ý rằng "thứ tự" không được bao gồm trong phản hồi tài nguyên. Nó không cần thiết - thứ tự được ngầm định cụ thể theo thứ tự phản hồi của các mục.
GET /list/order
trả về một danh sách các id mục theo đúng thứ tự của họ
['A','B','C','D','E']
POST /list/order với tải trọng ['D','B','C','A','E']
GET /list/order
trả về một danh sách các id mục theo đúng thứ tự của họ
['D','B','C','A','E']
Cũng rõ ràng là bạn sẽ quay trở lại các mục trong danh sách theo thứ tự đúng khi bạn làm một GET trên /list.
GET /list
trả về một danh sách các mục theo đúng thứ tự của họ
"items":" [
{
"id": "D",
"name": "Turkey"
},
{
"id": "B",
"name": "Cow"
},
{
"id": "C",
"name": "Horse"
},
{
"id": "A",
"name": "Monkey"
},
{
"id": "E",
"name": "Tasmanian Devil"
},
]
1 năm sau: Khi nó quay ra, ponderings triết học như vậy có tác động tối thiểu trên như thế nào ứng dụng của bạn giải quyết một vấn đề. Câu trả lời thực sự có vẻ là nó không quan trọng những gì bạn chọn miễn là bạn không vi phạm bất kỳ thông số kỹ thuật/yêu cầu và gây ra bất kỳ vấn đề. – dadads