A help-desk server holds 80,000 tickets. Users should be able to point the host at any ticket by its number, but the owners do not want resources/list to enumerate every ticket. Which design fits?
Select an answer to reveal the explanation.
Short Explanation
You don't print a phone book to call one number; you dial the pattern. A resource template gives clients the shape of a ticket URI so they can build any one on demand. Watch out for "pagination fixes it," because the owners said they don't want every ticket listed at all.
Full Explanation
Resource templates let a server expose parameterised resources using RFC 6570 URI templates. A template such as tickets://{id}, returned by resources/templates/list, tells the client how to construct the URI for any ticket, and the client then calls resources/read on the expanded URI. Template arguments can also be auto-completed through the completion API, which helps users pick valid ticket numbers. This makes every ticket addressable without enumerating them. Listing all tickets with pagination fails the stated requirement: pagination only splits a full enumeration into pages, so every ticket is still listed. A single resource returning all tickets fails by concept because individual tickets are no longer addressable, and each read would move the whole data set into context. Returning URIs from completion/complete without declaring resources fails because completion supplies suggested argument values for a prompt or a resource template reference; with no template there is nothing for it to complete, and completion results are capped at 100 values. Exam caveat: templates complement resources/list rather than replacing it; a server can still list a few important tickets directly. Operational check: call resources/templates/list, expand the template with a known ticket number, and confirm resources/read returns that ticket.