2013-04-23 40 views
6

Tôi đang xây dựng một hệ thống quản lý sự kiện. Giản đồ được mô tả dưới đây. API hiểu các mối quan hệ này và trả về các liên kết đến các tài nguyên có liên quan trong kết quả yêu cầu. Ví dụ,REST - mở rộng mối quan hệ

GET /Events/1 

    "links": { 
    "Venue": "/Venues/1", 
    "Tickets": "/Tickets?event_id=1", 
    "Teams": "/Teams?event_id=1", 
    "Registrations": "/Registrations?event_id=1" 
} 

Hầu hết những gì tôi đã đọc về REST và HATEOAS cho thấy đây là "đúng" cách để làm điều đó tuy nhiên nó là rất không hiệu quả. Ví dụ: nếu tôi muốn tạo báo cáo về người dùng và các nhóm tham gia sự kiện, nó yêu cầu nhiều yêu cầu. Điều này tương tự với việc chạy một số truy vấn chọn thay vì chạy một truy vấn nối duy nhất đối với một DB. Vì vậy, câu hỏi của tôi là, tôi có nên mở rộng các mối quan hệ và nhúng các tài nguyên có liên quan trong một yêu cầu tài nguyên không? Điều này cũng đặt ra một vấn đề b/c yêu cầu trên sẽ trả về rất nhiều dữ liệu. Câu trả lời có thể là gắn bó với các liên kết mối quan hệ và thiết lập bộ nhớ đệm thích hợp. Bất kể, tôi muốn ý kiến ​​của bạn.

Schema 

events 
    hasMany registrations 
    hasMany tickets 
    hasMany teams 

team 
    belongsTo event 

ticket 
    belongsTo event 
    hasMany registrations 

user 
    hasMany registrations 

registrations 
    belongsTo event 
    belongsTo ticket 
    belongsTo user 
    belongsTo team 

Trả lời

6

Không có gì sai khi trả lại toàn bộ tài nguyên trong phần nội dung của một yêu cầu khác. Điều này có thể được ở bên tiết, mặc dù, như bạn đã đề cập.

Cho rằng một số người gọi dịch vụ chỉ có thể muốn các URI trả về nhưng đôi khi bạn muốn giảm số chuyến đi vòng qua mạng, tức là bạn muốn mọi thứ trong một cuộc gọi, cụm từ bạn đang tìm kiếm là dự đoán.

Đây là các đại diện khác nhau về tài nguyên của bạn phục vụ cho nhu cầu của khách hàng.

Bạn có thể chỉ định các tham số trong một URI, ví dụ, GET /Events/1?venueProjection=full,teamProjection=uri

Và sau đó trả lại chiếu theo những gì khách hàng yêu cầu.

"links": { 
"Venue": { 
    "uri": "/Venues/1", 
    "attr1": "value1", 
    "attrN": "valueN" 
}, 
"Tickets": "/Tickets?event_id=1", 
"Teams": "/Teams?event_id=1", 
"Registrations": "/Registrations?event_id=1" 
} 

Lưu ý: Luôn mang URI với dự đoán của bạn do đó, nếu họ không đầy đủ, khách hàng có thể dễ dàng đến tài nguyên đầy đủ sau.

Tôi khuyên bạn nên thực hiện một số việc đọc xung quanh "các dự đoán còn lại" từ Google hoặc kiểm tra Sách nấu ăn RESTful.

+0

Cảm ơn bạn. Tôi không thể nói cho bạn biết có bao nhiêu hướng dẫn/hướng dẫn tôi đọc trực tuyến và không bao giờ gặp phải thuật ngữ hoặc khái niệm này. – newb1123

+0

Không thể tìm thấy bất kỳ điều gì về thuật ngữ này ...: S Btw. Vé, Đội, Đăng ký phải là đối tượng có thuộc tính url duy nhất thay vì chuỗi. Việc xử lý chúng dễ dàng hơn với khách hàng theo cách đó ... – inf3rno

+0

Tôi nhận được từ sách nấu ăn RESTFul. Về cơ bản nó là một cách khác để tinh chỉnh một "đại diện" mà không sử dụng thương lượng nội dung bình thường hoặc có hàng nghìn đại diện. Nó cho phép bạn về cơ bản xác định một đặc điểm kỹ thuật cho các đại diện mà bạn muốn. http://www.amazon.co.uk/RESTful-Services-Cookbook-Subbu-Allamaraju/dp/0596801688/ref=sr_1_1?ie=UTF8&qid=1378368152&sr=8-1&keywords=rest+cookbook – James

Các vấn đề liên quan