APIs

An API is the contract other software uses to talk to your model.

It is the boundary between the model and everything that depends on it.

REST over HTTP with JSON is the usual shape and is understood everywhere.

A request carries the input, and the response carries the prediction.

The caller never sees the model, the framework or the weights.

That separation is the point, since you can swap the model without touching a caller.

Version the API, because a change in output shape breaks everyone downstream.

Validate the input and return a clear error rather than a stack trace.

Return structured errors that a caller can act on programmatically.

Include a request identifier in the response so a complaint can be traced to a log line.

Set timeouts, since a model call that hangs will take the caller down with it.

For slow work, return a job identifier and let the caller poll or receive a callback.

Streaming responses suit language models, because the first token arrives long before the last.

Document the shape, the limits and the error cases, since undocumented APIs get used wrongly.

Health and readiness endpoints let the platform know whether to send traffic.