Quy ước REST URI - Tên số ít hoặc số nhiều của tài nguyên trong khi tạo tài nguyên

Tôi mới sử dụng REST và tôi đã quan sát thấy rằng trong một số dịch vụ RESTful, họ sử dụng URI tài nguyên khác nhau để cập nhật / nhận / xóa và Tạo. Nhu la

• Tạo - sử dụng / tài nguyên với phương thức POST (quan sát số nhiều) tại một số nơi sử dụng / resource (số ít)
• Cập nhật - sử dụng / resource / 123 với phương thức PUT
• Nhận - Sử dụng / resource / 123 với phương thức GET

Tôi hơi bối rối về quy ước đặt tên URI này. Chúng ta nên sử dụng số nhiều hay số ít để tạo tài nguyên? Điều gì nên là tiêu chí trong khi quyết định đó?

Tiền đề của việc sử dụng /resourceslà nó đại diện cho tài nguyên "tất cả". Nếu bạn làm một GET /resources, bạn có thể sẽ trả lại toàn bộ bộ sưu tập. Bằng cách gửi đến /resources, bạn đang thêm vào bộ sưu tập.

Tuy nhiên, các tài nguyên riêng lẻ có sẵn tại / resource. Nếu bạn làm một GET /resource, bạn có thể sẽ gặp lỗi, vì yêu cầu này không có ý nghĩa gì, trong khi lại /resource/123có ý nghĩa hoàn hảo.

Sử dụng /resourcethay vì /resourceslà tương tự như cách bạn sẽ làm điều này nếu bạn đang làm việc với, chẳng hạn, một hệ thống tập tin và một bộ sưu tập các tập tin và /resourcelà "thư mục" với các cá nhân 123, 456tập tin trong nó.

Không có cách nào là đúng hay sai, hãy đi với những gì bạn thích nhất.

Đối với tôi tốt hơn là có một lược đồ mà bạn có thể ánh xạ trực tiếp tới mã (dễ tự động hóa), chủ yếu vì mã là thứ sẽ có ở cả hai đầu.

GET  /orders          <---> orders 
POST /orders          <---> orders.push(data)
GET  /orders/1        <---> orders[1]
PUT  /orders/1        <---> orders[1] = data
GET  /orders/1/lines  <---> orders[1].lines
POST /orders/1/lines  <---> orders[1].lines.push(data) 

Tôi cũng không thấy điểm nào trong việc này và tôi nghĩ đó không phải là thiết kế URI tốt nhất. Là người dùng dịch vụ RESTful, tôi mong muốn tài nguyên danh sách có cùng tên cho dù tôi có truy cập danh sách hoặc tài nguyên cụ thể 'trong' danh sách. Bạn nên sử dụng cùng một mã định danh cho dù bạn muốn sử dụng tài nguyên danh sách hay tài nguyên cụ thể.

Số nhiều

• Đơn giản - tất cả các url bắt đầu với cùng một tiền tố
• Hợp lý - orders/có được một danh sách chỉ mục của các đơn đặt hàng.
• Tiêu chuẩn - Tiêu chuẩn được áp dụng rộng rãi nhất theo sau là phần lớn các API công khai và riêng tư.

Ví dụ:

GET /resources - trả về một danh sách các mục tài nguyên

POST /resources - tạo một hoặc nhiều mục tài nguyên

PUT /resources - cập nhật một hoặc nhiều mục tài nguyên

PATCH /resources - cập nhật một phần một hoặc nhiều mục tài nguyên

DELETE /resources - xóa tất cả các mục tài nguyên

Và đối với các mục tài nguyên đơn lẻ:

GET /resources/:id- trả về một mục tài nguyên cụ thể dựa trên :idtham số

POST /resources/:id - tạo một mục tài nguyên với id được chỉ định (yêu cầu xác thực)

PUT /resources/:id - cập nhật một mục tài nguyên cụ thể

PATCH /resources/:id - cập nhật một phần một mục tài nguyên cụ thể

DELETE /resources/:id - xóa một mục tài nguyên cụ thể

Đối với những người ủng hộ số ít, hãy nghĩ về nó theo cách này: Bạn sẽ hỏi ai đó về một orderđiều gì đó và mong đợi một điều, hoặc một danh sách các điều? Vậy tại sao bạn mong đợi một dịch vụ trả về một danh sách những thứ khi bạn gõ /order?

Số ít

Thuận tiện Mọi thứ có thể có tên số nhiều bất thường. Đôi khi họ không có. Nhưng tên Singular luôn ở đó.

ví dụ: Khách hàng Địa chỉ đối với Khách hàng Địa chỉ

Hãy xem xét tài nguyên liên quan này.

Điều này /order/12/orderdetail/12dễ đọc và hợp lý hơn /orders/12/orderdetails/4.

Bảng cơ sở dữ liệu

Một tài nguyên đại diện cho một thực thể như một bảng cơ sở dữ liệu. Nó nên có một tên số ít logic. Đây là câu trả lời trên tên bảng.

Ánh xạ lớp

Các lớp học luôn luôn là số ít. Các công cụ ORM tạo các bảng có cùng tên với tên lớp. Khi ngày càng có nhiều công cụ được sử dụng, các tên số ít đang trở thành một tiêu chuẩn.

Đọc thêm về Thế lưỡng nan của Nhà phát triển API REST

Trong khi thực tiễn phổ biến nhất là apis RESTful trong đó số nhiều được sử dụng /api/resources/123, ví dụ , có một trường hợp đặc biệt khi tôi thấy việc sử dụng một tên số ít thích hợp / biểu cảm hơn tên số nhiều. Đó là trường hợp của mối quan hệ một-một. Cụ thể nếu mục tiêu là một đối tượng giá trị (trong mô hình thiết kế hướng theo miền).

Chúng ta hãy giả sử rằng mọi tài nguyên đều có một accessLogcó thể được mô hình hóa thành một đối tượng giá trị, tức là không phải là một thực thể do đó không có ID. Nó có thể được thể hiện như /api/resources/123/accessLog. Các động từ thông thường (POST, PUT, DELETE, GET) sẽ thể hiện một cách thích hợp ý định và thực tế là mối quan hệ thực sự là một đối một.

Tại sao không theo xu hướng phổ biến của tên bảng cơ sở dữ liệu, trong đó một hình thức số ít thường được chấp nhận? Ở đó, làm điều đó - hãy tái sử dụng.

Bảng đặt tên tiến thoái lưỡng nan: Tên số ít so với số nhiều

Tôi ngạc nhiên khi thấy rằng rất nhiều người sẽ nhảy vào bandwagon danh từ số nhiều. Khi thực hiện chuyển đổi số ít sang số nhiều, bạn có quan tâm đến danh từ số nhiều không đều? Bạn có thích đau không?

Xem http://web2.uvcs.uvic.ca/elc/studyzone/330/grammar/irrplu.htmlm

Có nhiều loại số nhiều không đều, nhưng đây là những loại phổ biến nhất:

Loại danh từ Hình thành ví dụ số nhiều

Ends with -fe   Change f to v then Add -s   
    knife   knives 
    life   lives 
    wife   wives
Ends with -f    Change f to v then Add -es  
    half   halves 
    wolf   wolves
    loaf   loaves
Ends with -o    Add -es 
    potato   potatoes
    tomato   tomatoes
    volcano   volcanoes
Ends with -us   Change -us to -i    
    cactus   cacti
    nucleus   nuclei
    focus   foci
Ends with -is   Change -is to -es   
    analysis   analyses
    crisis   crises
    thesis   theses
Ends with -on   Change -on to -a    
    phenomenon   phenomena
    criterion   criteria
ALL KINDS   Change the vowel or Change the word or Add a different ending   
     man   men
     foot   feet
     child   children
     person   people
     tooth   teeth
     mouse   mice
 Unchanging Singular and plural are the same    
     sheep deer fish (sometimes)

Từ quan điểm của người tiêu dùng API, các điểm cuối sẽ có thể dự đoán được vì vậy

Lý tưởng nhất là ...

1. GET /resources nên trả về một danh sách các tài nguyên.
2. GET /resource nên trả về mã trạng thái 400 cấp.
3. GET /resources/id/{resourceId} sẽ trả về một bộ sưu tập với một tài nguyên.
4. GET /resource/id/{resourceId} nên trả về một đối tượng tài nguyên.
5. POST /resources Nên tạo tài nguyên hàng loạt.
6. POST /resource nên tạo một nguồn lực.
7. PUT /resource nên cập nhật một đối tượng tài nguyên.
8. PATCH /resource nên cập nhật một tài nguyên bằng cách chỉ đăng các thuộc tính đã thay đổi.
9. PATCH /resources Nên cập nhật hàng loạt tài nguyên chỉ đăng các thuộc tính thay đổi.
10. DELETE /resourcesnên xóa tất cả tài nguyên; đùa thôi: 400 mã trạng thái
11. DELETE /resource/id/{resourceId}

Cách tiếp cận này là linh hoạt nhất và giàu tính năng, nhưng cũng tốn thời gian nhất để phát triển. Vì vậy, nếu bạn đang vội (luôn luôn là trường hợp phát triển phần mềm), chỉ cần đặt tên cho điểm cuối của bạn resourcehoặc dạng số nhiều resources. Tôi thích hình thức số ít vì nó cung cấp cho bạn tùy chọn để xem xét và đánh giá theo chương trình vì không phải tất cả các hình thức số nhiều đều kết thúc bằng 's'.

Đã nói tất cả, vì bất kỳ lý do gì, các nhà phát triển thực hành được sử dụng phổ biến nhất đã chọn là sử dụng hình thức số nhiều. Đây cuối cùng là con đường tôi đã chọn và nếu bạn nhìn vào apis phổ biến như githubvà twitter, đây là những gì họ làm.

Một số tiêu chí để quyết định có thể là:

1. Hạn chế thời gian của tôi là gì?
2. Những hoạt động nào tôi sẽ cho phép người tiêu dùng của tôi làm?
3. Yêu cầu và tải trọng kết quả trông như thế nào?
4. Tôi có muốn sử dụng sự phản chiếu và phân tích URI trong mã của mình không?

Vì vậy, nó tùy thuộc vào bạn. Chỉ cần bất cứ điều gì bạn làm là nhất quán.

Hai xu của tôi: các phương pháp dành thời gian thay đổi từ số nhiều sang số ít hoặc ngược lại là một sự lãng phí chu kỳ CPU. Tôi có thể là trường học cũ, nhưng trong thời gian của tôi như mọi thứ được gọi là như nhau. Làm thế nào để tôi tìm kiếm các phương pháp liên quan đến mọi người? Không có biểu hiện thường xuyên sẽ bao gồm cả người và người mà không có tác dụng phụ không mong muốn.

Số nhiều tiếng Anh có thể rất độc đoán và họ mã hóa mã không cần thiết. Bám sát một quy ước đặt tên. Ngôn ngữ máy tính được cho là về sự rõ ràng toán học, không phải là bắt chước ngôn ngữ tự nhiên.

Tôi thích sử dụng hình thức số ít cho cả sự đơn giản và nhất quán.

Ví dụ: xem xét các url sau:

/ khách hàng / 1

Tôi sẽ coi khách hàng là bộ sưu tập của khách hàng, nhưng để đơn giản, phần bộ sưu tập bị loại bỏ.

Một vi dụ khac:

/ thiết bị / 1

Trong trường hợp này, thiết bị không phải là hình thức số nhiều chính xác. Vì vậy, coi nó như một bộ sưu tập thiết bị và loại bỏ bộ sưu tập cho đơn giản làm cho nó phù hợp với trường hợp khách hàng.

Một id trong một tuyến đường nên được xem giống như một chỉ mục cho một danh sách và việc đặt tên sẽ được tiến hành tương ứng.

numbers = [1, 2, 3]

numbers            GET /numbers
numbers[1]         GET /numbers/1
numbers.push(4)    POST /numbers
numbers[1] = 23    UPDATE /numbers/1

Nhưng một số tài nguyên không sử dụng id trong các tuyến đường của họ vì chỉ có một hoặc một người dùng không bao giờ có quyền truy cập vào nhiều hơn một, vì vậy những danh sách đó không có trong danh sách:

GET /dashboard
DELETE /session
POST /login
GET /users/{:id}/profile
UPDATE /users/{:id}/profile

Với các quy ước đặt tên, thường thì an toàn khi nói "chỉ cần chọn một và tuân theo nó", điều này có ý nghĩa.

Tuy nhiên, sau khi phải giải thích REST cho nhiều người, đại diện cho các điểm cuối là đường dẫn trên hệ thống tệp là cách thực hiện rõ ràng nhất.
Nó không trạng thái (các tệp tồn tại hoặc không tồn tại), phân cấp, đơn giản và quen thuộc - bạn đã biết cách truy cập các tệp tĩnh, cho dù cục bộ hoặc qua http.

Và trong bối cảnh đó, các quy tắc ngôn ngữ chỉ có thể giúp bạn đi xa như sau:

Một thư mục có thể chứa nhiều tệp và / hoặc thư mục con, và do đó tên của nó phải ở dạng số nhiều.

Và tôi thích điều đó.
Mặc dù, mặt khác - đó là thư mục của bạn, bạn có thể đặt tên cho nó là "a-resource-or-multi-resource" nếu đó là những gì bạn muốn. Đó không thực sự là điều quan trọng.

Điều quan trọng là nếu bạn đặt một tệp có tên "123" trong thư mục có tên "resourceS" (kết quả là /resourceS/123), thì bạn không thể mong đợi nó có thể truy cập được thông qua /resource/123.

Đừng cố làm cho nó thông minh hơn nó phải - thay đổi từ số nhiều sang số ít tùy thuộc vào số lượng tài nguyên bạn đang truy cập có thể làm hài lòng một số người, nhưng nó không hiệu quả và nó không có ý nghĩa hệ thống phân cấp .

Lưu ý: Về mặt kỹ thuật, bạn có thể tạo "liên kết tượng trưng", do đó /resources/123cũng có thể được truy cập qua /resource/123, nhưng trước đây vẫn phải tồn tại!

Hãy xem Hướng dẫn thiết kế API của Google : Tên tài nguyên để thực hiện việc đặt tên tài nguyên khác.

Nói ngắn gọn:

• Bộ sưu tập được đặt tên với số nhiều.
• Tài nguyên cá nhân được đặt tên bằng một chuỗi.

|--------------------------+---------------+-------------------+---------------+--------------|
| API Service Name         | Collection ID | Resource ID       | Collection ID | Resource ID  |
|--------------------------+---------------+-------------------+---------------+--------------|
| //mail.googleapis.com    | /users        | /name@example.com | /settings     | /customFrom  |
| //storage.googleapis.com | /buckets      | /bucket-id        | /objects      | /object-id   |
|--------------------------+---------------+-------------------+---------------+--------------|

Thật đáng để đọc nếu bạn đang nghĩ về chủ đề này.

Sử dụng số nhiều cho tất cả các phương thức là thực tế hơn ít nhất ở một khía cạnh: nếu bạn đang phát triển và thử nghiệm API tài nguyên bằng Postman (hoặc công cụ tương tự), bạn không cần chỉnh sửa URI khi chuyển từ GET sang PUT sang POST, v.v. .

Cả hai đại diện đều hữu ích. Tôi đã sử dụng số ít để thuận tiện trong một thời gian khá lâu, tình trạng viêm có thể khó khăn. Kinh nghiệm của tôi trong việc phát triển các API REST đơn lẻ nghiêm ngặt, các nhà phát triển sử dụng điểm cuối thiếu sự chắc chắn về hình dạng của kết quả có thể là gì. Bây giờ tôi thích sử dụng thuật ngữ mô tả đúng nhất hình dạng của phản hồi.

Nếu tất cả các tài nguyên của bạn ở cấp cao nhất, thì bạn có thể thoát khỏi các biểu diễn số ít. Tránh viêm là một chiến thắng lớn.

Nếu bạn đang thực hiện bất kỳ loại liên kết sâu nào để thể hiện các truy vấn về mối quan hệ, thì các nhà phát triển viết chống lại API của bạn có thể được hỗ trợ bằng cách có một quy ước chặt chẽ hơn.

Quy ước của tôi là mỗi cấp độ sâu trong URI đang mô tả sự tương tác với tài nguyên gốc và URI đầy đủ sẽ mô tả ngầm định những gì đang được truy xuất.

Giả sử chúng ta có mô hình sau.

interface User {
    <string>id;
    <Friend[]>friends;
    <Manager>user;
}

interface Friend {
    <string>id;
    <User>user;
    ...<<friendship specific props>>
}

Nếu tôi cần cung cấp một tài nguyên cho phép khách hàng có được người quản lý của một người bạn cụ thể của một người dùng cụ thể, thì nó có thể trông giống như:

GET /users/{id}/friends/{friendId}/manager

Sau đây là một số ví dụ khác:

• GET /users - liệt kê tài nguyên người dùng trong bộ sưu tập người dùng toàn cầu
• POST /users - tạo người dùng mới trong bộ sưu tập người dùng toàn cầu
• GET /users/{id} - lấy một người dùng cụ thể từ bộ sưu tập người dùng toàn cầu
• GET /users/{id}/manager - có được người quản lý của một người dùng cụ thể
• GET /users/{id}/friends - có được danh sách bạn bè của người dùng
• GET /users/{id}/friends/{friendId} - có được một người bạn cụ thể của người dùng
• LINK /users/{id}/friends - thêm một hiệp hội bạn bè cho người dùng này
• UNLINK /users/{id}/friends - xóa liên kết bạn bè khỏi người dùng này

Lưu ý cách mỗi cấp độ ánh xạ tới cha mẹ có thể được hành động. Sử dụng cha mẹ khác nhau cho cùng một đối tượng là phản trực giác. Lấy một tài nguyên tại các GET /resource/123lá mà không có dấu hiệu cho thấy việc tạo một tài nguyên mới nên được thực hiện tạiPOST /resources

Tôi biết hầu hết mọi người đang ở giữa quyết định nên sử dụng số nhiều hay số ít. Vấn đề chưa được giải quyết ở đây là khách hàng sẽ cần biết bạn đang sử dụng cái nào và họ luôn có khả năng mắc lỗi. Đây là nơi đề nghị của tôi đến từ.

Làm thế nào về cả hai? Và bằng cách đó, tôi có nghĩa là sử dụng số ít cho toàn bộ API của bạn và sau đó tạo các tuyến để chuyển tiếp các yêu cầu được thực hiện ở dạng số nhiều sang dạng số ít. Ví dụ:

GET  /resources     =     GET  /resource
GET  /resources/1   =     GET  /resource/1
POST /resources/1   =     POST /resource/1
...

Bạn nhận được hình ảnh. Không ai sai, nỗ lực tối thiểu và khách hàng sẽ luôn luôn làm đúng.

Tôi không muốn thấy {id}một phần của các URL trùng lặp với các tài nguyên phụ, vì idvề mặt lý thuyết có thể là bất cứ điều gì và sẽ có sự mơ hồ. Nó đang trộn các khái niệm khác nhau (định danh và tên tài nguyên phụ).

Vấn đề tương tự thường thấy trong enumcác hằng số cấu trúc thư mục hoặc các khái niệm khác nhau là hỗn hợp (ví dụ, khi bạn có thư mục Tigers, Lionsvà Cheetahs, và sau đó còn là một thư mục có tên Animalscùng cấp - điều này làm cho không có ý nghĩa là một là một tập hợp con của khác).

Nói chung, tôi nghĩ rằng phần được đặt tên cuối cùng của một điểm cuối nên là số ít nếu nó liên quan đến một thực thể duy nhất tại một thời điểm và số nhiều nếu nó liên quan đến một danh sách các thực thể.

Vì vậy, các điểm cuối liên quan đến một người dùng:

GET  /user             -> Not allowed, 400
GET  /user/{id}        -> Returns user with given id
POST /user             -> Creates a new user
PUT  /user/{id}        -> Updates user with given id
DELETE /user/{id}      -> Deletes user with given id

Sau đó, có tài nguyên riêng để thực hiện truy vấn trên người dùng, thường trả về một danh sách:

GET /users             -> Lists all users, optionally filtered by way of parameters
GET /users/new?since=x -> Gets all users that are new since a specific time
GET /users/top?max=x   -> Gets top X active users

Và đây là một số ví dụ về tài nguyên phụ liên quan đến một người dùng cụ thể:

GET /user/{id}/friends -> Returns a list of friends of given user

Kết bạn (liên kết nhiều đến nhiều):

PUT /user/{id}/friend/{id}     -> Befriends two users
DELETE /user/{id}/friend/{id}  -> Unfriends two users
GET /user/{id}/friend/{id}     -> Gets status of friendship between two users

Không bao giờ có bất kỳ sự mơ hồ nào, và việc đặt tên số nhiều hoặc số ít của tài nguyên là một gợi ý cho người dùng những gì họ có thể mong đợi (danh sách hoặc đối tượng). Không có hạn chế nào đối với ids, về mặt lý thuyết cho phép người dùng có id newmà không bị trùng lặp với tên tài nguyên phụ (tương lai tiềm năng).

Sử dụng Singular và tận dụng quy ước tiếng Anh được thấy trong ví dụ "Danh bạ doanh nghiệp".

Rất nhiều thứ được đọc theo cách này: "Vỏ sách", "Gói chó", "Phòng trưng bày nghệ thuật", "Liên hoan phim", "Lô xe", v.v.

Điều này thuận tiện phù hợp với đường dẫn url từ trái sang phải. Loại vật phẩm bên trái. Đặt loại bên phải.

Có GET /usersthực sự bao giờ lấy một tập hợp người dùng? Không thường xuyên. Nó tìm nạp một bộ sơ khai chứa khóa và có thể là tên người dùng. Vì vậy, nó không thực sự /usersdù sao. Đó là một chỉ mục của người dùng hoặc "chỉ mục người dùng" nếu bạn muốn. Tại sao không gọi nó là? Đó là một /user/index. Vì chúng tôi đã đặt tên cho loại thiết lập, chúng tôi có thể có nhiều loại hiển thị các hình chiếu khác nhau của người dùng mà không cần dùng đến các tham số truy vấn, ví dụ như user/phone-listhoặc/user/mailing-list .

Còn người dùng 300 thì sao? Nó vẫn vậy /user/300.

GET /user/index
GET /user/{id}

POST /user
PUT /user/{id}

DELETE /user/{id}

Khi kết thúc, HTTP chỉ có thể có một phản hồi cho một yêu cầu duy nhất. Một con đường luôn luôn đề cập đến một số ít.

Đối với tôi, số nhiều thao túng bộ sưu tập , trong khi số ít thao túng vật phẩm trong bộ sưu tập đó.

Bộ sưu tập cho phép các phương thức GET / POST / DELETE

Mục cho phép các phương thức GET / PUT / DELETE

Ví dụ

POST trên / sinh viên sẽ thêm một sinh viên mới trong trường.

XÓA trên / học sinh sẽ loại bỏ tất cả các học sinh trong trường.

XÓA vào / sinh viên / 123 sẽ loại bỏ sinh viên 123 khỏi trường.

Nó có thể cảm thấy như không quan trọng nhưng một số kỹ sư đôi khi quên id. Nếu tuyến đường luôn ở dạng số nhiều và thực hiện XÓA, bạn có thể vô tình xóa sạch dữ liệu của mình. Trong khi thiếu id trên số ít sẽ trả về một lộ trình 404 không tìm thấy.

Để tiếp tục mở rộng ví dụ nếu API được cho là phơi bày nhiều trường, thì đại loại như

XÓA trên / trường / abc / học sinh sẽ loại bỏ tất cả các học sinh trong trường abc.

Chọn từ đúng đôi khi là một thách thức của riêng nó, nhưng tôi thích duy trì số nhiều cho bộ sưu tập. Ví dụ cart_itemshoặc cart/itemscảm thấy đúng. Ngược lại xóa cart, xóa đối tượng giỏ hàng tự nó và không phải các mục trong giỏ hàng;).

Làm thế nào về:

/resource/(không /resource)

/resource/ có nghĩa là thư mục chứa thứ gọi là "tài nguyên", đó là thư mục "resouce".

Và tôi cũng nghĩ rằng quy ước đặt tên của các bảng cơ sở dữ liệu là giống nhau, ví dụ, một bảng có tên 'user' là "bảng người dùng", nó chứa một thứ gọi là "user".

Tôi thích sử dụng cả số nhiều ( /resources) và số ít (/resource/{id} ) vì tôi nghĩ rằng nó phân tách rõ ràng hơn logic giữa làm việc trên bộ sưu tập tài nguyên và làm việc trên một tài nguyên.

Là một tác dụng phụ quan trọng của việc này, nó cũng có thể giúp ngăn người khác sử dụng API sai. Ví dụ: hãy xem xét trường hợp người dùng cố gắng lấy tài nguyên sai bằng cách chỉ định Id là một tham số như thế này:

GET /resources?Id=123

Trong trường hợp này, khi chúng tôi sử dụng phiên bản số nhiều, máy chủ rất có thể sẽ bỏ qua tham số Id và trả về danh sách tất cả các tài nguyên. Nếu người dùng không cẩn thận, anh ta sẽ nghĩ rằng cuộc gọi đã thành công và sử dụng tài nguyên đầu tiên trong danh sách.

Mặt khác, khi sử dụng dạng số ít:

GET /resource?Id=123

máy chủ rất có thể sẽ trả về lỗi vì Id không được chỉ định đúng cách và người dùng sẽ phải nhận ra rằng có gì đó không đúng.