2012-02-07 59 views
8

Giả sử tôi muốn thiết kế một REST api nói về các bài hát, album và nghệ sĩ (thực sự tôi làm, như 1312414 người trước tôi).Cách thức xử lý mối quan hệ hai chiều giữa các tài nguyên

Tài nguyên bài hát luôn được liên kết với album đó là một phần của album. Ngược lại, tài nguyên album được liên kết với tất cả các bài hát chứa trong đó. Các hiệp hội được thể hiện trong các biểu diễn tài nguyên bằng cách liên kết.

Như vậy, cơ quan đại diện sẽ giống như thế này:

{ 
    song: 'xyz', 
    links: [ 
     { rel: 'album', url: '.../albums/abc' } 
    ] 
} 

{ 
    album: 'abc', 
    links: [ 
     { rel: 'song', url: '.../songs/xyz' }, 
     { rel: 'song', url: '...' }, 
     { rel: 'song', url: '...' }, 
     { rel: 'song', url: '...' } 
    ] 
} 

Given, mà tôi muốn điều này chứng minh chân lý (có lẽ vấn đề nằm ở chỗ "Do"), làm thế nào sau đó để tôi thiết kế API của tôi , sao cho việc tạo một album hoặc tài nguyên bài hát không có tác dụng phụ trên tài nguyên album hoặc bài hát hiện có trước đó?

Đây là một số vấn đề về gà/trứng. Nếu tôi tạo tài nguyên bài hát trước (POST/songs /) và sau đó tạo tài nguyên album (POST/albums /), tài nguyên bài hát sẽ được sửa đổi như một phần của quá trình tạo album (điều này không đúng theo nguyên tắc REST), vì liên kết giữa hai tài nguyên đang được cập nhật trên máy chủ. Tương tự như vậy đối với kịch bản mà tôi tạo album đầu tiên, bài hát thứ hai.

Tôi đoán tôi có thể tránh toàn bộ vấn đề bằng cách tránh tác dụng phụ trên máy chủ và vượt qua gánh nặng quản lý các mối quan hệ hai chiều với khách hàng.

Ngoài ra, tôi không muốn tạo album và bài hát về nguyên tử như một tổng thể. Điều duy nhất tôi có thể nghĩ đến ngay bây giờ, là bao gồm các tác dụng phụ nói trên trong ngữ nghĩa của API của tôi bằng cách trả lời một tạo tài nguyên với một đại diện có chứa một danh sách các liên kết đến các tài nguyên đã được sửa đổi như là một kết quả của yêu cầu. Điều đó làm cho tác dụng phụ rõ ràng, nhưng vẫn không yên tĩnh.

+0

tạo một bài hát, nếu nó có một trường album và album không tồn tại, hãy tạo album. tạo một album, nếu nó có bài hát không tồn tại, hãy tạo bài hát. – zzzzBov

+0

Một cách để xem nó là mỗi album và bài hát là một tài nguyên được đóng gói và các liên kết chỉ là biểu đồ kết nối chúng với nhau. Việc thay đổi các liên kết sẽ thay đổi mối quan hệ giữa các nguồn tài nguyên nhưng các nguồn tài nguyên không thực sự thay đổi. – abraham

+3

"tài nguyên bài hát được sửa đổi như là một phần của việc tạo album (điều này có hại theo nguyên tắc REST)" Nguyên tắc nào là? bạn có thể cung cấp một liên kết? Theo kinh nghiệm của tôi, việc cập nhật tài nguyên có tác dụng phụ trên các tài nguyên khác, mọi lúc. –

Trả lời

1

Không có gì về REST nói rằng thao tác trạng thái của một tài nguyên không thể thay đổi trạng thái của tài nguyên khác. Về REST gần nhất nhận được đó là khái niệm của hành động idempotent, mà nói rằng chỉ lặp đi lặp lại chúng sẽ dẫn đến trạng thái tương tự.

Vì vậy, trong trường hợp của bạn, không có gì vốn không chính xác về tài nguyên Song có thể, hiệu quả, tự thêm vào tài nguyên Album. Cũng không có bất kỳ điều gì sai về tài nguyên Album có thể nói rằng tài nguyên Song là một phần của tài nguyên.

Bây giờ, đưa ra yêu cầu kinh doanh, bạn có thể muốn a.) Thay đổi cách bạn thể hiện bài hát/album hoặc b.) Cho phép các bài hát/album liên quan theo kiểu m/m thay vì 1/1. Lý do cho điều này là, tùy thuộc vào cách bạn cấu trúc dữ liệu của bạn và chọn tài nguyên (tức là các đơn vị địa chỉ) trong hệ thống của bạn, bạn đang thực sự mô hình hóa các mối quan hệ dữ liệu khác nhau, và điều này, tôi nghĩ, là mấu chốt của vấn đề bạn đang gặp phải .

Với SongsAlbums các tài nguyên riêng biệt trong hệ thống của bạn, thực thi các mối quan hệ hạn chế hơn, như 1/1 thay vì m/m, yêu cầu nhiều công việc và đặc điểm kỹ thuật hơn trong các loại nội dung của bạn. Bạn phải xử lý các trường hợp hai album khác nhau đều nghĩ rằng chúng chứa một bài hát duy nhất, nhưng mối quan hệ 1/1 không cho phép điều đó.

Nếu bạn có một đối tượng Album rõ ràng chứa hoặc riêng các Song đối tượng, sau đó có ít của một vấn đề, vì một Album chỉ có thể vận dụng nó là bài hát của riêng và không những của bất kỳ Album khác. Tuy nhiên, thay đổi này là thay đổi mô hình dữ liệu, vì Songs không còn là công dân hạng nhất, thay vào đó là bên dưới album sở hữu chúng.

Đây là điểm mấu chốt của toàn bộ vấn đề ... bạn phải quyết định ai sở hữu mối quan hệ.

Không có gì sai với cả hai bên (AlbumSong) sở hữu nó. Điều này làm việc hoàn hảo cho một mối quan hệ m/m, nhưng đối với mối quan hệ 1/1, điều đó đòi hỏi chi phí quản lý cao hơn nhiều (nghĩa là một cái gì đó khác thực sự sở hữu mối quan hệ).

Nếu bạn muốn có một mối quan hệ 1/1 mà không cần tất cả các chi phí, tuy nhiên, bạn cần phải có một của các đối tượng tham gia sở hữu mối quan hệ, có nghĩa là chỉ có một đường dẫn đến thay đổi nó ... thông qua pháp nhân sở hữu.

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