2012-01-10 27 views
7

Là một dự án lập trình cá nhân, tôi đang làm việc để cạo danh mục khóa học của Đại học và cung cấp dữ liệu dưới dạng API REST. Tôi đã cạo thành công tất cả dữ liệu và lưu trữ nó trong một cơ sở dữ liệu, và bây giờ tôi đang làm việc trên API.Cách tốt nhất để thiết kế một API REST với nhiều bộ lọc?

Các khóa học có thể được lọc trên cơ sở nhiều tiêu chí: giảng viên, đại học, các khoản tín dụng, thời gian, ngày, vv

cách tốt nhất để cung cấp một API trong tình huống này là gì?

Lựa chọn 1

Cung cấp nhiều URL như

example.com/api/byinstructor/<instructorcode> 
example.come/api/bycollege/<collegecode> 
example.com/api/bycollegeandinstructor/<collegecode>/<instructorcode> 
...and so on 

tôi sẽ cần phải có một URL cho tất cả các hoán vị. Điều này có vẻ rất cồng kềnh, cả cho tôi và người tiêu dùng API, và rất không có DRY.

Lựa chọn 2

Chỉ cung cấp các API cho các tùy chọn lớn như:

example.com/api/byinstructor/<instructorcode> 
example.come/api/bycollege/<collegecode> 

Và nếu người tiêu dùng muốn bycollegeandinstructor, anh ấy làm việc lọc trên cuối cùng của mình.

Lựa chọn 3

Người dùng vượt qua một chuỗi JSON với tôi, và tôi sử dụng để có được những tiêu chí lọc

example.com/api/getcourses/<jsonstring> 

jsonstring = 
{ 
    instructor:<instructorcode>, 
    college:<collegecode>, 
    ...and so on 
} 

Tôi cho rằng thay vì chuỗi Json, tôi cũng có thể yêu cầu một POST mảng, nhưng điều đó có vẻ không trực quan cho người tiêu dùng kể từ khi anh ta đang nhận dữ liệu.

Hoặc có cách nào khác để làm điều này mà tôi không biết? Nếu đó là tùy chọn thứ ba là tùy chọn tốt nhất, bạn có thể cung cấp tóm tắt ngắn nhất để chuẩn bị truy vấn SQL trên cơ sở chuỗi JSOn có thể có số lượng giá trị biến không?

Trả lời

13

Mở rộng trên câu trả lời từ JF, có vẻ như bạn có một nguồn lực, tập các khóa học, trong đó sẽ có mặt tại URI:

/courses 

Lọc tài nguyên thường được thực hiện sử dụng truy vấn các tham số để lọc tài nguyên đơn lẻ đó, ví dụ:

/courses?college=123&instructor=321 

Bằng cách này, bạn tránh vấn đề với tất cả các hoán vị có thể tạo ra sự gia tăng tài nguyên.

Về cơ bản: Có một tài nguyên, có thể được lọc khi cần thiết.

+0

Thanls. Tôi đã không suy nghĩ về nguồn lực cho đến khi tôi đọc câu trả lời yhour – xbonez

+6

Về mặt kỹ thuật, đó vẫn là các tài nguyên khác biệt.Bạn không thực sự tránh các vấn đề hoán vị theo cách này; trên thực tế, bạn tăng những vấn đề này một chút bằng cách cho phép college = 123 & instructor = 321 trả về cùng một câu trả lời như hướng dẫn = 321 & college = 123. Vì sự bùng nổ này, nhiều bộ nhớ cache sẽ không lưu trữ một phản hồi có tham số truy vấn trừ khi bạn định cấu hình chúng một cách rõ ràng để làm như vậy. Vì lý do đó, tôi thường khuyên bạn nên chọn tùy chọn 2 nếu bạn có thể xác định một số mẫu phổ biến trong các yêu cầu mà mọi người thực hiện. – fumanchu

+0

@fumanchu Điều thú vị về bộ nhớ cache bỏ qua phản hồi cho các yêu cầu có tham số truy vấn, tôi không biết điều đó. Cảm ơn. – Pete

5
GET example.com/courses?college=<collegecode>&instructor=<instructorcode> 
+0

và người tiêu dùng được phép chuyển bao nhiêu hoặc ít thông số GET tùy thích? – xbonez

+0

@xbonez: vâng. Trong trường hợp không có ràng buộc, bạn có thể sử dụng các giá trị mặc định thích hợp cho ứng dụng của mình, ví dụ: cá nhân hóa việc lọc nếu người dùng được biết. – jfs

+0

hoàn hảo. cảm ơn bạn – xbonez

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