Client and exceptions¶
The connection, the free-function wrapper, and the exception hierarchy.
MidasClient¶
midas_nx.client.MidasClient
¶
A configured connection to one MIDAS NX Open API server.
Example::
client = MidasClient(mapi_key="...", product=Product.CIVIL)
client.request("POST", "/doc/NEW", {"Argument": {}})
request(method, command, body=None, *, timeout=None)
¶
Send one request. timeout overrides the client default for this
call only; omitting it keeps the client's own timeout.
Pass a (connect, read) tuple to bound the two phases separately —
useful for calls that are known to hang once the product has accepted
them (the *-ANAL design-check family), where you want to give up
waiting quickly and read the result back with a follow-up GET instead
of blocking on a response that may never arrive. A timeout is not a
rollback: the product may well finish the operation after the client
has stopped waiting.
verify_connection(*, timeout=None)
¶
GET {base url with the /gen or /civil product segment removed}/mapikey/verify.
Docs: the MIDAS-API manual repo's docs/AUTHENTICATION.md, "연결 전 상태
확인 — /mapikey/verify" — a health-check endpoint documented in the
repo's auth guide rather than a per-chapter manual page (so it isn't
tracked in docs/coverage.json/ROADMAP.md alongside the itemized
endpoint surface). Distinguishes three cases: HTTP 200 with
"status": "connected"/"keyVerified": True (healthy — the
product process is alive and this MAPI-Key is valid for it); HTTP 200
with "status": "disconnected" (product not connected — returned
as-is, not raised, since it's a normal response shape, not an HTTP
error); and HTTP 404 with a "client does not exist" message (the
product process died after connecting — surfaced as
MidasNotFoundError like any other 404). Useful as a sanity check
right after constructing a client, or before a batch of calls that
would otherwise each hit their own timeout if the product has
silently died.
⚠️ This is not a preflight check, and a "connected" answer does not
mean the next call will work. While the product is showing a modal
dialog — a confirmation prompt, an access-denied error, a crash-
recovery notice — the relay keeps answering /mapikey/verify with
"connected" while every /db/* call on that same session times
out until a human dismisses the dialog. Confirmed live. So treat a
healthy answer here as "the key is valid and the process was alive a
moment ago", not as clearance to run a destructive operation. There
is no API-visible signal for a dialog-blocked session; the only
reliable check is a cheap real call (e.g. a small GET) and a
short timeout.
Product¶
midas_nx.client.Product
¶
Bases: str, Enum
Module-level helpers¶
midas_nx.client.configure(**kwargs)
¶
Reconfigure the process-wide default client.
Example::
configure(mapi_key="...", product=Product.CIVIL)
MidasAPI("POST", "/doc/NEW", {"Argument": {}})
midas_nx.client.get_default_client()
¶
Return the process-wide default client, constructing it lazily from MIDAS_MAPI_KEY / MIDAS_BASE_URL env vars on first use.
midas_nx.client.MidasAPI(method, command, body=None)
¶
Free-function convenience wrapper around the default client.
Matches the calling convention documented in the MIDAS-API manual repo's README.md and examples/python/basic_example.py.
midas_nx.client.build_base_url(product)
¶
Build the default global Base URL for a product.
Regional variants (e.g. -in/-kr/-gb/-us/.cn hostnames,
used by MIDASIT's official SDKs) are not documented in the MIDAS-API
manual and are intentionally not guessed at here — pass base_url
explicitly to MidasClient if you need one. See docs/coverage.json.
Exceptions¶
All of these descend from MidasAPIError, so a single except MidasAPIError
catches everything this SDK raises — including the client-side guards, which
raise before any request is sent.
midas_nx.client.MidasAPIError
¶
Bases: Exception
Base class for all errors raised by this SDK.
Subclasses may set HINT to a short, actionable suggestion; it's
appended to the message automatically so callers see both the server's
own error text and, where there's a common fix, what to do about it.
midas_nx.client.MidasAuthError
¶
midas_nx.client.MidasNotFoundError
¶
midas_nx.client.MidasRequestError
¶
midas_nx.client.MidasServerError
¶
midas_nx.client.MidasConnectionError
¶
midas_nx.client.MidasResultError
¶
Bases: MidasAPIError
HTTP 200, but the body carries an {"error": {...}} object.
Several endpoints report a refusal this way instead of with an HTTP error
status — e.g. a story table asked for before ope.calculate_story() has
run, or a design check whose preconditions aren't met. Treating the 2xx as
success hands the caller an error dict that looks like a result, so the
client raises instead. Pass MidasClient(raise_on_result_error=False) to
get the raw body back and inspect it yourself.
midas_nx.client.ProductMismatchError
¶
midas_nx.client.UnsupportedMethodError
¶
Bases: MidasAPIError
Raised when a resource doesn't support the requested HTTP method (e.g. calling .create() on a GET/PUT-only endpoint like MATD).
midas_nx.client.DestructiveOperationError
¶
Bases: MidasAPIError
Raised when a call that would destroy model data was made without
explicitly confirming it (e.g. DbResource.delete_all() without
confirm=True).
Raised before anything is sent, so nothing has changed on the server when you see this. There is no undo through the API, and the products have no confirmation dialog on the API path, so the guard is here rather than in the product.