Thực tiễn tốt nhất cho các tài nguyên lồng nhau REST là gì?


301

Theo như tôi có thể nói mỗi tài nguyên riêng lẻ chỉ nên có một đường dẫn chính tắc . Vì vậy, trong ví dụ sau đây các mẫu URL tốt sẽ là gì?

Lấy một ví dụ đại diện phần còn lại của các công ty. Trong ví dụ giả thuyết này, mỗi công ty sở hữu 0 phòng ban trở lên và mỗi bộ phận sở hữu 0 nhân viên trở lên.

Một bộ phận không thể tồn tại mà không có một công ty liên kết.

Một nhân viên không thể tồn tại mà không có bộ phận liên quan.

Bây giờ tôi sẽ tìm thấy sự biểu diễn tự nhiên của các mẫu tài nguyên.

  • /companies Một bộ sưu tập các công ty - Chấp nhận đặt cho một công ty mới. Nhận cho toàn bộ bộ sưu tập.
  • /companies/{companyId}Một công ty cá nhân. Chấp nhận NHẬN, PUT và XÓA
  • /companies/{companyId}/departmentsChấp nhận POST cho một mục mới. (Tạo một bộ phận trong công ty.)
  • /companies/{companyId}/departments/{departmentId}/
  • /companies/{companyId}/departments/{departmentId}/employees
  • /companies/{companyId}/departments/{departmentId}/employees/{empId}

Với các ràng buộc, trong mỗi phần, tôi cảm thấy rằng điều này có ý nghĩa nếu một chút sâu sắc lồng nhau.

Tuy nhiên, khó khăn của tôi đến nếu tôi muốn liệt kê ( GET) tất cả nhân viên trên tất cả các công ty.

Mẫu tài nguyên cho điều đó sẽ ánh xạ chặt chẽ nhất tới /employees(Bộ sưu tập của tất cả nhân viên)

Điều đó có nghĩa là tôi cũng nên có /employees/{empId}vì nếu vậy thì có hai URI để có cùng một tài nguyên?

Hoặc có thể toàn bộ lược đồ nên được làm phẳng nhưng điều đó có nghĩa là các nhân viên là một đối tượng cấp cao nhất lồng nhau.

Ở cấp độ cơ bản /employees/?company={companyId}&department={deptId}trả về cùng một quan điểm chính xác của nhân viên là mô hình lồng nhau sâu sắc nhất.

Cách thực hành tốt nhất cho các mẫu URL nơi tài nguyên được sở hữu bởi các tài nguyên khác nhưng phải có thể truy vấn riêng biệt?


1
Đây gần như chính xác là vấn đề oppsite được mô tả trong stackoverflow.com/questions/7104578/ Khăn mặc dù các câu trả lời có thể liên quan. Cả hai câu hỏi là về quyền sở hữu nhưng ví dụ đó ngụ ý rằng đối tượng cấp cao nhất không phải là chủ sở hữu.
Wes

1
Chính xác những gì tôi đã tự hỏi về. Đối với trường hợp sử dụng nhất định, giải pháp của bạn có vẻ ổn, nhưng nếu mối quan hệ là một tập hợp chứ không phải là một thành phần thì sao? Vẫn đang đấu tranh để tìm ra cách thực hành tốt nhất ở đây ... Ngoài ra, giải pháp này chỉ ngụ ý việc tạo ra mối quan hệ, ví dụ như một người hiện có được tuyển dụng hoặc nó tạo ra một đối tượng người?
Jakob O.

Nó tạo ra một người trong ví dụ hư cấu của tôi. Lý do tôi sử dụng các thuật ngữ tên miền đó là một ví dụ hợp lý dễ hiểu, mặc dù bắt chước vấn đề thực tế của tôi. Bạn đã xem qua các câu hỏi được liên kết có thể khiến bạn mất nhiều thời gian hơn cho một mối quan hệ khó chịu.
Wes

Tôi đã chia câu hỏi của tôi thành một câu trả lời và một câu hỏi.
Wes

Câu trả lời:


152

Những gì bạn đã làm là chính xác. Nói chung, có thể có nhiều URI cho cùng một tài nguyên - không có quy tắc nào nói rằng bạn không nên làm điều đó.

Và nói chung, bạn có thể cần truy cập trực tiếp vào các mục hoặc dưới dạng tập hợp con của một thứ khác - vì vậy cấu trúc của bạn có ý nghĩa với tôi.

Chỉ vì nhân viên có thể truy cập theo bộ phận:

company/{companyid}/department/{departmentid}/employees

Không có nghĩa là họ cũng không thể truy cập theo công ty:

company/{companyid}/employees

Mà sẽ trả lại nhân viên cho công ty đó. Nó phụ thuộc vào những gì cần thiết bởi khách hàng tiêu dùng của bạn - đó là những gì bạn nên thiết kế cho.

Nhưng tôi hy vọng rằng tất cả các trình xử lý URL sử dụng cùng một mã sao lưu để đáp ứng các yêu cầu để bạn không bị trùng lặp mã.


11
Điều này đang chỉ ra tinh thần của RESTful, không có quy tắc nào nói rằng bạn nên hay không nên làm nếu chỉ xem xét một tài nguyên có ý nghĩa trước tiên. Nhưng xa hơn, tôi tự hỏi đâu là cách thực hành tốt nhất để không sao chép mã trong các tình huống như vậy.
abookyun

13
@abookyun nếu bạn cần cả hai tuyến, thì mã điều khiển lặp lại giữa chúng có thể được trừu tượng hóa thành các đối tượng dịch vụ.
bgcode

Điều này không có gì để làm với REST. REST không quan tâm đến cách bạn cấu trúc phần đường dẫn của URL của mình ... tất cả những gì nó quan tâm là hợp lệ, hy vọng các URI bền bỉ ...
redben

Hướng đến câu trả lời này, tôi nghĩ rằng bất kỳ api nào trong đó các phân đoạn động đều là các định danh duy nhất không cần phải xử lý nhiều phân đoạn động ( /company/3/department/2/employees/1). Nếu api cung cấp các cách để nhận từng tài nguyên, thì việc thực hiện từng yêu cầu đó có thể được thực hiện trong thư viện phía máy khách hoặc dưới dạng điểm cuối một lần sử dụng lại mã.
tối đa

1
Mặc dù không có sự cấm đoán nào, tôi cho rằng nó thanh lịch hơn khi chỉ có một con đường dẫn đến một tài nguyên - giữ cho tất cả các mô hình tinh thần đơn giản hơn. Tôi cũng thích các URI không thay đổi loại tài nguyên của chúng nếu có bất kỳ lồng nhau nào. ví dụ /company/*chỉ nên trả lại tài nguyên công ty và không thay đổi loại tài nguyên nào cả. Không ai trong số này được chỉ định bởi REST - nó thường được chỉ định kém - chỉ là sở thích cá nhân.
kashif

174

Tôi đã thử cả hai chiến lược thiết kế - các điểm cuối lồng nhau và không lồng nhau. Tôi đã thấy rằng:

  1. nếu tài nguyên lồng nhau có khóa chính và bạn không có khóa chính của nó, cấu trúc lồng nhau yêu cầu bạn phải lấy nó, mặc dù hệ thống không thực sự yêu cầu nó.

  2. điểm cuối lồng nhau thường yêu cầu điểm cuối dự phòng. Nói cách khác, bạn sẽ thường xuyên hơn không, cần điểm cuối bổ sung / nhân viên để bạn có thể nhận được danh sách nhân viên giữa các phòng ban. Nếu bạn có / nhân viên, chính xác những gì / công ty / phòng ban / nhân viên mua cho bạn?

  3. các điểm cuối lồng nhau không tiến hóa độc đáo. Ví dụ, bạn có thể không cần tìm kiếm nhân viên ngay bây giờ nhưng sau này bạn có thể và nếu bạn có cấu trúc lồng nhau, bạn không có lựa chọn nào khác ngoài việc thêm một điểm cuối khác. Với thiết kế không lồng nhau, bạn chỉ cần thêm nhiều tham số, đơn giản hơn.

  4. đôi khi một nguồn tài nguyên có thể có nhiều loại cha mẹ. Kết quả là nhiều điểm cuối đều trả về cùng một tài nguyên.

  5. điểm cuối dự phòng làm cho các tài liệu khó viết hơn và cũng làm cho api khó học hơn.

Nói tóm lại, thiết kế không lồng nhau dường như cho phép một lược đồ điểm cuối linh hoạt và đơn giản hơn.


24
Đã rất mới mẻ để đi qua câu trả lời này. Tôi đã sử dụng các thiết bị đầu cuối lồng nhau trong vài tháng nay sau khi được dạy rằng đó là "cách đúng đắn". Tôi đã đi đến tất cả các kết luận tương tự mà bạn liệt kê ở trên. Vì vậy, dễ dàng hơn nhiều với một thiết kế không lồng nhau.
user344977

6
Bạn dường như liệt kê một số nhược điểm là những mặt trái. "Chỉ nhồi nhét thêm các tham số vào một điểm cuối duy nhất" làm cho API khó hơn để ghi chép và tìm hiểu, chứ không phải theo cách khác. ;-)
Drenmi

4
Không phải là một fan hâm mộ của câu trả lời này. Không cần phải giới thiệu các điểm cuối dự phòng chỉ vì bạn đã thêm tài nguyên lồng nhau. Đây cũng không phải là vấn đề khi có cùng một tài nguyên được trả lại bởi nhiều cha mẹ, miễn là những phụ huynh đó thực sự sở hữu tài nguyên lồng nhau. Không có vấn đề gì để có được tài nguyên gốc để tìm hiểu cách tương tác với các tài nguyên lồng nhau. Một API REST có thể khám phá tốt nên làm điều này.
Scottm

3
@Scottm - Một nhược điểm của các tài nguyên lồng nhau mà tôi gặp phải là nó có thể dẫn đến việc trả lại dữ liệu không chính xác nếu id tài nguyên gốc không chính xác / không khớp. Giả sử không có vấn đề ủy quyền, việc triển khai api còn lại để xác minh rằng tài nguyên lồng nhau thực sự là con của tài nguyên mẹ được thông qua. Nếu kiểm tra này không được mã hóa, phản hồi api có thể không chính xác dẫn đến tham nhũng. Quan điểm của bạn là gì?
Andy Dufresne

1
Bạn không cần id cha trung gian nếu tất cả tài nguyên cuối đều có id duy nhất. Vd bạn có thể truy cập các tài nguyên trung gian để lọc / tạo / sửa đổi và giúp tôi có thể khám phá theo quan điểm của tôi.
PaulG

77

Tôi đã chuyển những gì tôi đã làm từ câu hỏi sang một câu trả lời nơi nhiều người có khả năng nhìn thấy nó.

Những gì tôi đã làm là có các điểm cuối tạođiểm cuối lồng nhau, Điểm cuối chuẩn để sửa đổi hoặc truy vấn một mục không nằm trong tài nguyên lồng nhau .

Vì vậy, trong ví dụ này (chỉ liệt kê các điểm cuối thay đổi tài nguyên)

  • POST /companies/ tạo một công ty mới trả về một liên kết đến công ty đã tạo.
  • POST /companies/{companyId}/departments Khi một bộ phận được đặt sẽ tạo ra bộ phận mới trả về một liên kết đến /departments/{departmentId}
  • PUT /departments/{departmentId} sửa đổi một bộ phận
  • POST /departments/{deparmentId}/employees tạo một nhân viên mới trả về một liên kết đến /employees/{employeeId}

Vì vậy, có các tài nguyên cấp gốc cho mỗi bộ sưu tập. Tuy nhiên, việc tạo là trong các đối tượng sở hữu .


4
Tôi đã đưa ra cùng một loại thiết kế. Tôi nghĩ thật trực quan khi tạo ra những thứ như "nơi chúng thuộc về", nhưng sau đó vẫn có thể liệt kê chúng trên toàn cầu. Thậm chí nhiều hơn khi có một mối quan hệ trong đó tài nguyên PHẢI có cha mẹ. Sau đó, việc tạo tài nguyên đó trên toàn cầu không làm cho điều đó trở nên rõ ràng, nhưng thực hiện nó trong một tài nguyên phụ như thế này có ý nghĩa hoàn hảo.
Joakim

Tôi đoán bạn đã sử dụng POSTý nghĩa PUT, và nếu không.
Gerardo Lima

Trên thực tế không Lưu ý rằng tôi không sử dụng Id được gán trước để tạo vì máy chủ trong trường hợp này chịu trách nhiệm trả lại id (trong liên kết). Do đó, viết POST là chính xác (không thể thực hiện cùng một cách thực hiện). Tuy nhiên, thay đổi toàn bộ tài nguyên nhưng nó vẫn có sẵn tại cùng một vị trí vì vậy tôi PUT nó. PUT vs POST là một vấn đề khác và cũng gây tranh cãi. Ví dụ: stackoverflow.com/questions/630453/put-vs-post-in-rest
Wes

@Wes Thậm chí tôi thích sửa đổi các phương thức động từ ở dưới gốc. Nhưng, bạn có thấy việc truyền tham số truy vấn cho tài nguyên toàn cầu được chấp nhận tốt không? Ví dụ: POST / bộ phận có tham số truy vấn company = company-id
Ayyappa

1
@Mohamad Nếu bạn nghĩ rằng cách khác dễ dàng hơn cả trong việc hiểu và áp dụng các ràng buộc thì hãy đưa ra câu trả lời. Về việc làm cho ánh xạ rõ ràng trong trường hợp này. Nó có thể hoạt động với một tham số nhưng thực sự đó là câu hỏi gì. Cách tốt nhất là gì.
Wes

35

Tôi đã đọc tất cả các câu trả lời ở trên nhưng có vẻ như chúng không có chiến lược chung. Tôi đã tìm thấy một bài viết hay về các thực tiễn tốt nhất trong API thiết kế từ Tài liệu Microsoft . Tôi nghĩ bạn nên tham khảo.

Trong các hệ thống phức tạp hơn, việc cung cấp các URI cho phép khách hàng điều hướng qua một số cấp độ mối quan hệ, chẳng hạn như /customers/1/orders/99/products.mức độ phức tạp này có thể khó duy trì và không linh hoạt nếu mối quan hệ giữa các tài nguyên thay đổi trong tương lai. Thay vào đó, hãy cố gắng giữ URI tương đối đơn giản . Khi một ứng dụng có tham chiếu đến tài nguyên, có thể sử dụng tham chiếu này để tìm các mục liên quan đến tài nguyên đó. Truy vấn trước có thể được thay thế bằng URI /customers/1/ordersđể tìm tất cả các đơn đặt hàng cho khách hàng 1 và sau đó /orders/99/productsđể tìm các sản phẩm theo thứ tự này.

.

tiền boa

Tránh yêu cầu URI tài nguyên phức tạp hơn collection/item/collection.


3
Tài liệu tham khảo bạn đưa ra thật tuyệt vời cùng với điểm bạn nổi bật vì không tạo ra các URI phức tạp.
Abbeyco

Vì vậy, khi tôi muốn tạo một nhóm cho người dùng, nên là POST / nhóm (userId in thebody) hoặc POST / users /: id / Đội
coinhndp

@coinhndp Xin chào, Bạn nên sử dụng POST / nhóm và bạn có thể nhận userId sau khi ủy quyền mã thông báo truy cập. Ý tôi là khi bạn tạo một thứ bạn cần mã ủy quyền, phải không? Tôi không biết bạn đang sử dụng khuôn khổ nào nhưng tôi chắc chắn bạn có thể có được userId trong bộ điều khiển API. Ví dụ: Trong ASP.NET API, hãy gọi RequestContext.Principal từ bên trong một phương thức trên ApiControll. Trong Spring Secirity, SecurityContextHolder.getContext (). GetAuthentication (). GetPrincipal () sẽ giúp bạn. Trong AWS NodeJS Lambda, đó là cognito: tên người dùng trong đối tượng tiêu đề.
Long Nguyên

Vì vậy, có gì sai với POST / users /: id / đội. Tôi nghĩ rằng nó được khuyến nghị trong Tài liệu Microsoft mà bạn đã đăng ở trên
coinhndp

@coinhndp Nếu bạn tạo nhóm với tư cách quản trị viên, điều đó thật tốt. Nhưng, như những người dùng bình thường, tôi không biết tại sao bạn cần userId trong đường dẫn? Tôi cho rằng chúng ta có user_A và user_B, bạn nghĩ sao nếu user_A có thể tạo một nhóm mới cho user_B nếu user_A gọi POST / users / user_B / đội. Vì vậy, không cần phải vượt qua userId trong trường hợp này, userId có thể nhận được sau khi ủy quyền. Nhưng, các nhóm /: id / dự án là tốt để tạo mối quan hệ giữa nhóm và dự án chẳng hạn.
Long Nguyễn

10

Các URL của bạn trông như thế nào không liên quan gì đến REST. Bất cứ điều gì đi. Nó thực sự là một "chi tiết thực hiện". Vì vậy, giống như cách bạn đặt tên cho các biến của bạn. Tất cả chúng phải là duy nhất và bền.

Đừng lãng phí quá nhiều thời gian cho việc này, chỉ cần đưa ra lựa chọn và kiên định với nó / nhất quán. Ví dụ: nếu bạn đi với hệ thống phân cấp thì bạn làm điều đó cho tất cả các tài nguyên của bạn. Nếu bạn đi với các tham số truy vấn ... vv giống như các quy ước đặt tên trong mã của bạn.

Tại sao vậy ? Theo như tôi biết API "RESTful" có thể duyệt được (bạn biết ... "Hypermedia là Công cụ của Trạng thái Ứng dụng"), do đó, ứng dụng API không quan tâm đến URL của bạn như thế nào miễn là chúng hợp lệ (không có SEO, không có con người cần đọc những "url thân thiện" đó, ngoại trừ có thể để gỡ lỗi ...)

URL đẹp như thế nào / dễ hiểu trong API REST chỉ thú vị đối với bạn với tư cách là nhà phát triển API, không phải ứng dụng khách API, như tên của một biến trong mã của bạn.

Điều quan trọng nhất là ứng dụng khách API của bạn biết cách diễn giải loại phương tiện của bạn. Ví dụ, nó biết rằng:

  • loại phương tiện của bạn có thuộc tính liên kết liệt kê các liên kết có sẵn / liên quan.
  • Mỗi liên kết được xác định bởi một mối quan hệ (giống như các trình duyệt biết rằng liên kết [rel = "biểu định kiểu"] có nghĩa là biểu định kiểu hoặc rel = favico là liên kết đến favicon ...)
  • và nó biết ý nghĩa của các mối quan hệ đó ("công ty" có nghĩa là danh sách các công ty, "tìm kiếm" có nghĩa là url được tạo khuôn mẫu để thực hiện tìm kiếm trên danh sách tài nguyên, "bộ phận" có nghĩa là bộ phận của tài nguyên hiện tại)

Dưới đây là một ví dụ trao đổi HTTP (các nội dung nằm trong yaml vì nó dễ viết hơn):

Yêu cầu

GET / HTTP/1.1
Host: api.acme.io
Accept: text/yaml, text/acme-mediatype+yaml

Trả lời: danh sách các liên kết đến tài nguyên chính (công ty, con người, bất cứ điều gì ...)

HTTP/1.1 200 OK
Date: Tue, 05 Apr 2016 15:04:00 GMT
Last-Modified: Tue, 05 Apr 2016 00:00:00 GMT
Content-Type: text/acme-mediatype+yaml

# body: this is your API's entrypoint (like a homepage)  
links:
  # could be some random path https://api.acme.local/modskmklmkdsml
  # the only thing the API client cares about is the key (or rel) "companies"
  companies: https://api.acme.local/companies
  people: https://api.acme.local/people

Yêu cầu: liên kết đến các công ty (sử dụng phản hồi trước đó là body.links.compiances)

GET /companies HTTP/1.1
Host: api.acme.local
Accept: text/yaml, text/acme-mediatype+yaml

Trả lời: một danh sách một phần các công ty (theo mục), tài nguyên chứa các liên kết liên quan, như liên kết để có được một vài công ty tiếp theo (body.links.next) một liên kết (templated) khác để tìm kiếm (body.links.search)

HTTP/1.1 200 OK
Date: Tue, 05 Apr 2016 15:06:00 GMT
Last-Modified: Tue, 05 Apr 2016 00:00:00 GMT
Content-Type: text/acme-mediatype+yaml

# body: representation of a list of companies
links:
  # link to the next page
  next: https://api.acme.local/companies?page=2
  # templated link for search
  search: https://api.acme.local/companies?query={query} 
# you could provide available actions related to this resource
actions:
  add:
    href: https://api.acme.local/companies
    method: POST
items:
  - name: company1
    links:
      self: https://api.acme.local/companies/8er13eo
      # and here is the link to departments
      # again the client only cares about the key department
      department: https://api.acme.local/companies/8er13eo/departments
  - name: company2
    links:
      self: https://api.acme.local/companies/9r13d4l
      # or could be in some other location ! 
      department: https://api2.acme.local/departments?company=8er13eo

Vì vậy, như bạn thấy nếu bạn đi theo cách liên kết / quan hệ, cách bạn cấu trúc phần đường dẫn của URL không có bất kỳ giá trị nào đối với ứng dụng khách API của bạn. Và nếu bạn đang truyền đạt cấu trúc URL của mình tới khách hàng của mình dưới dạng tài liệu, thì bạn không thực hiện REST (hoặc ít nhất là không phải Cấp 3 theo " mô hình trưởng thành của Richardson ")


7
"URL đẹp như thế nào / dễ hiểu trong API REST chỉ thú vị đối với bạn với tư cách là nhà phát triển API, không phải ứng dụng khách API, như tên của một biến trong mã của bạn." Tại sao điều này KHÔNG thú vị? Điều này rất quan trọng, nếu bất cứ ai trừ chính bạn cũng đang sử dụng API. Đây là một phần của trải nghiệm người dùng, vì vậy tôi muốn nói rằng điều này rất dễ hiểu đối với các nhà phát triển ứng dụng khách API. Làm cho mọi thứ trở nên dễ hiểu hơn bằng cách liên kết các tài nguyên rõ ràng dĩ nhiên là một phần thưởng (cấp 3 trong url bạn cung cấp). Mọi thứ nên trực quan và logic với các mối quan hệ rõ ràng.
Joakim

1
@Joakim Nếu bạn đang tạo API nghỉ ngơi cấp 3 (Hypertext As The Engine Of Application State), thì cấu trúc đường dẫn của url hoàn toàn không được khách hàng quan tâm (miễn là nó hợp lệ). Nếu bạn không nhắm đến cấp 3, thì có, điều đó rất quan trọng và có thể đoán được. Nhưng REST thực sự là cấp 3. Một bài viết hay: martinfowler.com/articles/richardsonMaturityModel.html
redben

4
Tôi phản đối việc tạo API hoặc UI không thân thiện với con người. Cấp 3 hay không, tôi đồng ý liên kết tài nguyên là một ý tưởng tuyệt vời. Nhưng để đề xuất làm như vậy "làm cho nó có thể thay đổi lược đồ URL" là không phù hợp với thực tế và cách mọi người sử dụng API. Vì vậy, đó là một đề nghị xấu. Nhưng chắc chắn trong tất cả các thế giới, mọi người đều sẽ ở Cấp 3 REST. Tôi kết hợp các siêu liên kết VÀ sử dụng sơ đồ URL dễ hiểu của con người. Cấp 3 không loại trừ cái trước, và theo tôi thì tôi nên quan tâm. Bài viết hay :)
Joakim

Tất nhiên mọi người nên quan tâm đến lợi ích của khả năng duy trì và các mối quan tâm khác, tôi nghĩ rằng bạn bỏ lỡ điểm của câu trả lời của tôi: cách url trông không xứng đáng với nhiều suy nghĩ và bạn nên "chỉ cần lựa chọn và tuân theo / nhất quán "như tôi đã nói trong câu trả lời. Và trong trường hợp API REST, ít nhất theo ý kiến ​​của tôi, sự thân thiện với người dùng không nằm trong url, chủ yếu là ở (loại phương tiện) Dù sao tôi cũng hy vọng bạn hiểu quan điểm của tôi :)
redben

9

Tôi không đồng ý với loại con đường này

GET /companies/{companyId}/departments

Nếu bạn muốn có được các phòng ban, tôi nghĩ tốt hơn là sử dụng tài nguyên / phòng ban

GET /departments?companyId=123

Tôi cho rằng bạn có một companiesbảng và một departmentsbảng sau đó các lớp để ánh xạ chúng theo ngôn ngữ lập trình bạn sử dụng. Tôi cũng cho rằng các phòng ban có thể được gắn vào các thực thể khác ngoài các công ty, vì vậy tài nguyên / phòng ban rất đơn giản, thật tiện lợi khi có các tài nguyên được ánh xạ tới các bảng và bạn cũng không cần nhiều điểm cuối vì bạn có thể sử dụng lại

GET /departments?companyId=123

cho bất kỳ loại tìm kiếm nào, ví dụ

GET /departments?name=xxx
GET /departments?companyId=123&name=xxx
etc.

Nếu bạn muốn tạo một bộ phận,

POST /departments

tài nguyên nên được sử dụng và cơ quan yêu cầu nên chứa ID công ty (nếu bộ phận có thể được liên kết với chỉ một công ty).


1
Đối với tôi, đây là một cách tiếp cận chấp nhận được chỉ khi đối tượng lồng nhau có ý nghĩa như một đối tượng nguyên tử. Nếu họ không, sẽ thực sự có ý nghĩa để phá vỡ chúng.
Simme

Đây là những gì tôi đã nói, nếu bạn cũng muốn có thể truy xuất các phòng ban, nghĩa là nếu bạn sẽ sử dụng điểm cuối / phòng ban.
Maxime Laval

2
Cũng có thể có ý nghĩa khi cho phép các bộ phận được bao gồm thông qua tải lười biếng khi tìm nạp công ty, ví dụ GET /companies/{companyId}?include=departments, vì điều này cho phép cả công ty và các bộ phận của công ty được tìm nạp trong một yêu cầu HTTP. Fractal làm điều này thực sự tốt.
Matthew Daly

1
Khi bạn thiết lập acls, có lẽ bạn muốn hạn chế /departmentsđiểm cuối chỉ có thể truy cập bởi quản trị viên và mỗi công ty chỉ truy cập vào các phòng ban của họ thông qua `/ công ty / {companyId} /
phòng`

@MatthewDaly OData cũng làm điều đó một cách độc đáo với $ mở rộng
Rob Grant

1

Rails cung cấp một giải pháp cho việc này: làm tổ nông .

Tôi nghĩ rằng điều này là tốt bởi vì khi bạn giao dịch trực tiếp với một tài nguyên đã biết, không cần sử dụng các tuyến đường lồng nhau, như đã được thảo luận trong các câu trả lời khác ở đây.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.