Aller au contenu principal
Version : 11.x

Spécification HTTP RPC

Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Correspondance Méthodes <-> Types

HTTP MethodMappingNotes
GET.query()Input JSON-stringified in query param.
e.g. myQuery?input=${encodeURIComponent(JSON.stringify(input))}
POST.mutation()Input as POST body.
n/a.subscription()Subscriptions are not supported in HTTP transport

Accès aux procédures imbriquées

Les procédures imbriquées sont séparées par des points. Ainsi, une requête vers byId ci-dessous aboutirait à une requête vers /api/trpc/post.byId.

ts
export const appRouter = router({
post: router({
byId: publicProcedure.input(String).query(async (opts) => {
// [...]
}),
}),
});
ts
export const appRouter = router({
post: router({
byId: publicProcedure.input(String).query(async (opts) => {
// [...]
}),
}),
});

Traitement par lot (Batching)

Lors du traitement par lot, nous combinons tous les appels de procédures parallèles utilisant la même méthode HTTP en une seule requête à l'aide d'un data loader.

  • Les noms des procédures appelées sont combinés par une virgule (,) dans le pathname

  • Les paramètres d'entrée sont envoyés via un paramètre de requête appelé input ayant la forme Record<number, unknown>.

  • Nous devons également passer batch=1 comme paramètre de requête.

  • Si la réponse comporte différents statuts, nous renvoyons 207 Multi-Status (par exemple si un appel a échoué et un autre a réussi)

Exemple de requête groupée

Avec un routeur exposé à /api/trpc comme ceci :

server/router.ts
tsx
export const appRouter = t.router({
postById: t.procedure.input(String).query(async (opts) => {
const post = await opts.ctx.post.findUnique({
where: { id: opts.input },
});
return post;
}),
relatedPosts: t.procedure.input(String).query(async (opts) => {
const posts = await opts.ctx.findRelatedPostsById(opts.input);
return posts;
}),
});
server/router.ts
tsx
export const appRouter = t.router({
postById: t.procedure.input(String).query(async (opts) => {
const post = await opts.ctx.post.findUnique({
where: { id: opts.input },
});
return post;
}),
relatedPosts: t.procedure.input(String).query(async (opts) => {
const posts = await opts.ctx.findRelatedPostsById(opts.input);
return posts;
}),
});

... Et deux requêtes définies ainsi dans un composant React :

MyComponent.tsx
tsx
export function MyComponent() {
const post1 = trpc.postById.useQuery('1');
const relatedPosts = trpc.relatedPosts.useQuery('1');
return (
<pre>
{JSON.stringify(
{
post1: post1.data ?? null,
relatedPosts: relatedPosts.data ?? null,
},
null,
4,
)}
</pre>
);
}
MyComponent.tsx
tsx
export function MyComponent() {
const post1 = trpc.postById.useQuery('1');
const relatedPosts = trpc.relatedPosts.useQuery('1');
return (
<pre>
{JSON.stringify(
{
post1: post1.data ?? null,
relatedPosts: relatedPosts.data ?? null,
},
null,
4,
)}
</pre>
);
}

Ceci générerait exactement 1 appel HTTP avec ces données :

Location propertyValue
pathname/api/trpc/postById,relatedPosts
search?batch=1&input=%7B%220%22%3A%221%22%2C%221%22%3A%221%22%7D *

*) input ci-dessus résulte de :

ts
encodeURIComponent(
JSON.stringify({
0: '1', // <-- input for `postById`
1: '1', // <-- input for `relatedPosts`
}),
);
ts
encodeURIComponent(
JSON.stringify({
0: '1', // <-- input for `postById`
1: '1', // <-- input for `relatedPosts`
}),
);

Exemple de réponse groupée

Example output from server
json
[
// result for `postById`
{
"result": {
"data": {
"id": "1",
"title": "Hello tRPC",
"body": "..."
// ...
}
}
},
// result for `relatedPosts`
{
"result": {
"data": [
/* ... */
]
}
}
]
json
[
// result for `postById`
{
"result": {
"data": {
"id": "1",
"title": "Hello tRPC",
"body": "..."
// ...
}
}
},
// result for `relatedPosts`
{
"result": {
"data": [
/* ... */
]
}
}
]

Spécification des réponses HTTP

Pour disposer d'une spécification indépendante de la couche de transport, nous nous efforçons de respecter JSON-RPC 2.0 lorsque possible.

Réponse de succès

Example JSON Response
json
{
"result": {
"data": {
"id": "1",
"title": "Hello tRPC",
"body": "..."
}
}
}
json
{
"result": {
"data": {
"id": "1",
"title": "Hello tRPC",
"body": "..."
}
}
}
ts
{
result: {
data: TOutput; // output from procedure
}
}
ts
{
result: {
data: TOutput; // output from procedure
}
}

Réponse d'erreur

Example JSON Response
json
[
{
"error": {
"json": {
"message": "Something went wrong",
"code": -32600, // JSON-RPC 2.0 code
"data": {
// Extra, customizable, meta data
"code": "INTERNAL_SERVER_ERROR",
"httpStatus": 500,
"stack": "...",
"path": "post.add"
}
}
}
}
]
json
[
{
"error": {
"json": {
"message": "Something went wrong",
"code": -32600, // JSON-RPC 2.0 code
"data": {
// Extra, customizable, meta data
"code": "INTERNAL_SERVER_ERROR",
"httpStatus": 500,
"stack": "...",
"path": "post.add"
}
}
}
}
]

  • Lorsque possible, nous propageons les codes de statut HTTP de l'erreur levée.

  • Si la réponse comporte différents statuts, nous renvoyons 207 Multi-Status (par exemple si un appel a échoué et un autre a réussi)

  • Pour plus d'informations sur les erreurs et leur personnalisation, consultez Formatage des erreurs.

Correspondance Codes d'erreur <-> Statuts HTTP

ts
PARSE_ERROR: 400,
BAD_REQUEST: 400,
UNAUTHORIZED: 401,
FORBIDDEN: 403,
NOT_FOUND: 404,
METHOD_NOT_SUPPORTED: 405,
TIMEOUT: 408,
CONFLICT: 409,
PRECONDITION_FAILED: 412,
PAYLOAD_TOO_LARGE: 413,
UNSUPPORTED_MEDIA_TYPE: 415,
UNPROCESSABLE_CONTENT: 422,
PRECONDITION_REQUIRED: 428,
TOO_MANY_REQUESTS: 429,
CLIENT_CLOSED_REQUEST: 499,
INTERNAL_SERVER_ERROR: 500,
NOT_IMPLEMENTED: 501,
BAD_GATEWAY: 502,
SERVICE_UNAVAILABLE: 503,
GATEWAY_TIMEOUT: 504,
ts
PARSE_ERROR: 400,
BAD_REQUEST: 400,
UNAUTHORIZED: 401,
FORBIDDEN: 403,
NOT_FOUND: 404,
METHOD_NOT_SUPPORTED: 405,
TIMEOUT: 408,
CONFLICT: 409,
PRECONDITION_FAILED: 412,
PAYLOAD_TOO_LARGE: 413,
UNSUPPORTED_MEDIA_TYPE: 415,
UNPROCESSABLE_CONTENT: 422,
PRECONDITION_REQUIRED: 428,
TOO_MANY_REQUESTS: 429,
CLIENT_CLOSED_REQUEST: 499,
INTERNAL_SERVER_ERROR: 500,
NOT_IMPLEMENTED: 501,
BAD_GATEWAY: 502,
SERVICE_UNAVAILABLE: 503,
GATEWAY_TIMEOUT: 504,

Correspondance Codes d'erreur <-> Codes d'erreur JSON-RPC 2.0

Available codes & JSON-RPC code
ts
/**
* JSON-RPC 2.0 Error codes
*
* `-32000` to `-32099` are reserved for implementation-defined server-errors.
* For tRPC we're copying the last digits of HTTP 4XX errors.
*/
export const TRPC_ERROR_CODES_BY_KEY = {
/**
* Invalid JSON was received by the server.
* An error occurred on the server while parsing the JSON text.
*/
PARSE_ERROR: -32700,
/**
* The JSON sent is not a valid Request object.
*/
BAD_REQUEST: -32600, // 400
// Internal JSON-RPC error
INTERNAL_SERVER_ERROR: -32603, // 500
NOT_IMPLEMENTED: -32603, // 501
BAD_GATEWAY: -32603, // 502
SERVICE_UNAVAILABLE: -32603, // 503
GATEWAY_TIMEOUT: -32603, // 504
// Implementation specific errors
UNAUTHORIZED: -32001, // 401
FORBIDDEN: -32003, // 403
NOT_FOUND: -32004, // 404
METHOD_NOT_SUPPORTED: -32005, // 405
TIMEOUT: -32008, // 408
CONFLICT: -32009, // 409
PRECONDITION_FAILED: -32012, // 412
PAYLOAD_TOO_LARGE: -32013, // 413
UNSUPPORTED_MEDIA_TYPE: -32015, // 415
UNPROCESSABLE_CONTENT: -32022, // 422
PRECONDITION_REQUIRED: -32028, // 428
TOO_MANY_REQUESTS: -32029, // 429
CLIENT_CLOSED_REQUEST: -32099, // 499
} as const;
ts
/**
* JSON-RPC 2.0 Error codes
*
* `-32000` to `-32099` are reserved for implementation-defined server-errors.
* For tRPC we're copying the last digits of HTTP 4XX errors.
*/
export const TRPC_ERROR_CODES_BY_KEY = {
/**
* Invalid JSON was received by the server.
* An error occurred on the server while parsing the JSON text.
*/
PARSE_ERROR: -32700,
/**
* The JSON sent is not a valid Request object.
*/
BAD_REQUEST: -32600, // 400
// Internal JSON-RPC error
INTERNAL_SERVER_ERROR: -32603, // 500
NOT_IMPLEMENTED: -32603, // 501
BAD_GATEWAY: -32603, // 502
SERVICE_UNAVAILABLE: -32603, // 503
GATEWAY_TIMEOUT: -32603, // 504
// Implementation specific errors
UNAUTHORIZED: -32001, // 401
FORBIDDEN: -32003, // 403
NOT_FOUND: -32004, // 404
METHOD_NOT_SUPPORTED: -32005, // 405
TIMEOUT: -32008, // 408
CONFLICT: -32009, // 409
PRECONDITION_FAILED: -32012, // 412
PAYLOAD_TOO_LARGE: -32013, // 413
UNSUPPORTED_MEDIA_TYPE: -32015, // 415
UNPROCESSABLE_CONTENT: -32022, // 422
PRECONDITION_REQUIRED: -32028, // 428
TOO_MANY_REQUESTS: -32029, // 429
CLIENT_CLOSED_REQUEST: -32099, // 499
} as const;

Surcharger la méthode HTTP par défaut

Pour remplacer la méthode HTTP utilisée pour les requêtes/mutations, utilisez l'option methodOverride :

server/httpHandler.ts
tsx
// Your server must separately allow the client to override the HTTP method
const handler = createHTTPHandler({
router: router,
allowMethodOverride: true,
});
server/httpHandler.ts
tsx
// Your server must separately allow the client to override the HTTP method
const handler = createHTTPHandler({
router: router,
allowMethodOverride: true,
});
client/trpc.ts
tsx
// The client can then specify which HTTP method to use for all queries/mutations
const client = createTRPCClient<AppRouter>({
links: [
httpLink({
url: `http://localhost:3000`,
methodOverride: 'POST', // all queries and mutations will be sent to the tRPC Server as POST requests.
}),
],
});
client/trpc.ts
tsx
// The client can then specify which HTTP method to use for all queries/mutations
const client = createTRPCClient<AppRouter>({
links: [
httpLink({
url: `http://localhost:3000`,
methodOverride: 'POST', // all queries and mutations will be sent to the tRPC Server as POST requests.
}),
],
});

Approfondir

Vous trouverez plus de détails en explorant les définitions TypeScript dans :