Skip to main content
api.edicus.io는 실패를 4xx와 5xx 상태 코드로 알리고, body는 언제나 같은 모양입니다. 클라이언트는 상태 코드로 실패를 알아채고 error.code로 원인을 구분합니다. 리소스 호스트는 방식이 다르므로 따로 봅니다.

오류 body

“요청을 처리하지 못했다”는 4xx와 5xx이고, “처리했지만 답이 아니오다”는 200입니다. 예를 들어 can_order: false, 프리뷰 URL 여러 개 조회의 항목별 error는 200 안에 담겨 옵니다. 확인을 한 곳에 모아 두는 방법은 Server API 호출하기에 있습니다.

상태 코드별 error.code

엔드포인트마다 실제로 낼 수 있는 코드는 Server API 레퍼런스의 각 페이지에 있습니다.
error.code는 앞으로 늘어날 수 있습니다. 모르는 코드는 상태 코드 기준으로 처리하세요. 예를 들어 모르는 409는 “지금 상태에서는 할 수 없음”으로 다룹니다.

검증 실패의 details

400 invalid_request는 details.issues에 어긋난 항목을 담아 보냅니다. 각 항목의 path가 문제의 헤더나 필드 이름입니다.
issues의 각 항목은 디버깅용입니다. 화면에 그대로 보여 주거나 message를 파싱하지 마세요.

200이지만 기대한 값이 없는 경우

아래는 오류가 아니라 정상 응답입니다. 필드가 비었는지 직접 확인하세요.
  • 프로젝트 소유자 조회: 없는 프로젝트면 {"owner": null}이 옵니다.
  • 프리뷰 URL 조회: 프리뷰가 없거나 없는 프로젝트면 {"urls": []}가 옵니다.
  • 폰트 그룹 조회: 없는 그룹이면 {"font_group_id": "...", "fonts": null}이 옵니다.
  • 프리뷰 URL 여러 개 조회: 프리뷰 정보가 없는 항목은 results[i].error가 no_preview_urls입니다.

리소스 호스트

resource-dot-edicusbase.appspot.com(/resapi, /manapi)은 오류 모양이 다릅니다. error 객체가 없습니다. body만으로는 원인을 알 수 없는 경우가 많으니 상태 코드와 호출한 엔드포인트를 함께 로그에 남기세요.

실패 판정 순서

응답 하나를 받았을 때 아래 순서로 보시면 됩니다.
1

HTTP 상태 코드가 2xx가 아니다

실패입니다. api.edicus.io라면 error.code로 원인을 구분하고 request_id를 로그에 남깁니다. 리소스 호스트라면 위 표를 보세요.
2

2xx다

성공입니다. 비동기 복제는 202로 옵니다. 다만 위 “200이지만 기대한 값이 없는 경우”에 해당하는 엔드포인트는 필드가 비었는지 직접 확인하세요.

타임아웃

Edicus는 요청 타임아웃을 따로 규정하지 않습니다. 호출하는 쪽에서 거세요. 30초를 기본으로 두시면 대부분 충분합니다.
포토북처럼 이미지가 많은 프로젝트의 동기 복제는 수십 초 이상 걸릴 수 있습니다. 타임아웃을 늘리기보다 비동기 복제(POST /v2/projects/:project_id/clone_async)를 쓰시는 편이 낫습니다.

uid 형식 오류

사용자 단위 요청에 edicus-uid 헤더가 없거나 형식 규칙을 어기면 400 invalid_request입니다. 어느 엔드포인트가 이 헤더를 요구하는지는 Server API 레퍼런스에 표시돼 있으니, 보내기 전에 호출하는 쪽에서 먼저 막아 두시면 디버깅이 쉬워집니다.

다음 단계

Server API 레퍼런스

엔드포인트별 오류 응답을 봅니다.

주문

잠정 주문과 확정 주문의 흐름을 봅니다.