요약

  • APNIC의 현재 OpenAPI 사양에서 배치 요청은create,update,delete를 구분하는 반면, 결과 항목은status와message만 선언합니다.
  • 유용한 제어 수단은 소박합니다. 즉, 인덱스 또는 불투명 키, 작업 계열, 이슈 코드, 가능하다면 대상 리소스를 가리키는 안전한 참조입니다.

운영자에게 불확실성은 장애가 없어도 찾아옵니다. 아주 평범한 배치 하나로 충분합니다. 생성할 라우트 객체 두 개, 수정할 객체 하나, 삭제할 객체 하나. API는 요청을 검증하고 비동기 작업의 주소를 반환한 뒤 작업을 처리합니다. 이후 작업에는 여러 결과가 담깁니다.

APNIC의 공개 문서는 이러한 결과의 어휘를 명시합니다.status필드는success,failure,notification값을 가질 수 있고,message가 이에 동반될 수 있습니다. 그러나 항목에는 원래 배열의 이름도, 요청 내 위치도, 클라이언트가 제공한 키도, 리소스 식별자도,location도 없습니다. 문서는 각 작업마다 별도 항목이 있을 것이라 밝히지만, 응답 순서가 요청 순서를 재현한다는 규칙은 정하지 않습니다.

이 관찰은 파일에 대한 것이지 사건에 대한 것이 아닙니다. 검토한 OpenAPI는 버전0.0.2, 형식3.0.0, 59,622바이트 1,934행입니다. 인증된 배치는 전송되지 않았습니다. 운영 서비스가 응답을 재정렬하거나 두 작업을 혼동하거나 회원에게 실제로 추측을 강요한다는 증거는 없습니다. APNIC은 안정적인 순서를 유지하고, 메시지에 대상을 포함하고, 자체 로그에서 정확한 상관관계를 보관하고 있을 수 있습니다.

한계는 더 좁습니다. 이 보장이 참조한 머신 계약에는 없다는 것입니다.

APNIC의 가장 좋은 방어는 이미 먼저 있습니다

공개된 아키텍처에는 이미 여러 좋은 결정이 담겨 있습니다. POST, PUT, DELETE 쓰기는 작업 객체로 처리됩니다. 요청은 먼저 검증되고, 클라이언트는 이후 조회할 수 있는 링크를 받습니다. 작업은 초기 내용을 보관하고, 완료 시 처리 시각, HTTP 코드, 응답 본문을 제시할 수 있습니다.

배치 결과도 전체 예/아니오로 축소되지 않습니다. APNIC는 작업과 알림을 위한 별도 행을 마련합니다. 머리말은 배치가 가능한 한 트랜잭션적으로 적용되며, 일반적으로 Whois에 영향을 주지 않는 상호작용은 트랜잭션적으로 처리된다고 명시합니다. 읽기 작업과 MyAPNIC 뷰는 추가로 대조 수단을 제공합니다.

공개적 접점도 있습니다. APNIC는 출시 전 테스트 환경을 공개했고, 해커톤을 개최했으며, APNIC 58에서 제품을 시연했고, 하나는 비공개이고 하나는 공개인 두 개의 피드백 주소를 발표했습니다. 클라이언트 팀은 통합을 검증하고 설명을 요청할 수 있습니다.

압축된 스키마 선택은 의도적일 수 있습니다. 순서 규약은 코드에서 예외 없이 적용될 수 있습니다. 메시지는 일상적 용도에 충분히 명시적일 수 있습니다. 트랜잭션은 중간 상태 수를 줄일 수 있습니다. 그리고 내부 테스트가 APNIC이 공개적으로 상세히 설명하지 않는 보장을 보호할 수 있습니다.

이러한 우호적 가정은 중요합니다. 본 글은 어떤 작업이 유실, 중복 또는 잘못된 객체에 적용되었다고 말하지 않습니다. 회원이 피해를 입었다고 말하지도 않습니다. 비공개 로그, 데이터베이스 토폴로지, 레지스트리 데이터도 요구하지 않습니다. 오직 자동화에 필수적인 관계가 명시되기를 요구할 뿐입니다.

요청에는 주소가 있고, 응답에는 없습니다

요청 스키마는 세심하게 구조화되어 있습니다. 역방향 DNS, 라우트, ASPA의 경우 배치는 작업을create,update,delete로 나눕니다. 각 항목의 형태는 객체 유형과 작업에 따라 달라집니다. 라우트 삭제는 식별자를 대상으로 할 수 있습니다. RDNS 삭제는 범위를 대상으로 합니다. ASPA 수정은 식별자, 고객 ASN, 공급자 ASN 목록을 연결할 수 있습니다.

이 구조는 각 작업에 자연스럽게 주소를 부여합니다. 리소스 계열, 작업 유형, 배열 내 위치. 클라이언트는 예컨대delete의 항목 1을 보냈다는 것을 압니다.

공통 응답 스키마는 이 주소를 지웁니다.results아래 내부 객체는 두 속성만 선언합니다.status는 일반적 결과를 설명하고,message는 정의된 머신 문법 없이 문자열에 불과합니다. “이것은delete[1]에 대한 응답이다”라고 말하는 필드는 없습니다.

아마도 위치만으로도 실무에 충분할 수 있습니다. 그러나 순서는 명시되었을 때만 제어 수단입니다.create다음update, 다음delete를 이어 붙여야 할까요? 알림은 위치를 차지할까요? 거부된 검증은 한 행을 만들까요? 취소된 트랜잭션은 작업당 한 행을 반환할까요, 아니면 그룹 결과일까요? 검토한 문서는 이 질문들을 결정하지 않습니다.

OpenAPI 표준은 두 번째 뉘앙스를 더합니다. 객체 스키마에서 언급된 속성이 자동으로 필수가 되는 것은 아닙니다.required배열에 포함될 때 필수가 됩니다. 그런데batch-response는 최상위에 이 배열이 없습니다. 따라서 문서는type과results를 허용하지만 최소 형태로 강제하지는 않습니다.task,task-link,success-response스키마도 같은 특성을 보입니다.

다시 말하지만, 이는 서버가 이러한 필드를 생략한다는 뜻이 아닙니다. 클라이언트 생성기나 계약 테스트가 파일만으로 보장을 도출할 수 없다는 뜻입니다.

순서 가정은 부채가 됩니다

실험실 시나리오를 생각해 봅시다. APNIC 관찰이 아닙니다. 배치에 생성 세 개와 삭제 두 개가 들어 있습니다. 응답은 순서대로success,failure,success,success,notification을 제공합니다. 클라이언트에게 공개된 규칙이 없다면 여러 해석이 가능합니다. 알림은 독립 행일 수 있습니다. 실패는 두 번째 생성, 첫 번째 삭제 또는 전체 트랜잭션을 가리킬 수 있습니다. 메시지는 사람에게는 의심을 해소할 수 있지만 프로그램에 안정적인 키는 제공하지 않습니다.

그러면 자동화는 결국 자신만의 계약을 만들어 냅니다. 한 팀은 순서를 가정합니다. 다른 팀은 텍스트를 분석합니다. 셋째는 각 배치를 단일 호출로 분해합니다. 넷째는 쓰기 후 모든 리소스를 다시 읽습니다.

이 방법들의 비용은 다릅니다. 단일 호출은 모호성을 줄이지만 배치의 효율성과 때로는 트랜잭션 이점을 포기합니다. 전면 대조는 읽기, 지연, 레이트 한도 압박을 더합니다. 메시지 분석은 문구가 바뀔 때까지 작동합니다. 암묵적 순서는 알림이나 새 작업 유형이 추가될 때까지 작동합니다.

부담은 공평히 분배되지 않습니다. 큰 운영자는 어댑터, 테스트 세트, 경보를 유지할 수 있습니다. 작은 팀은 흔히 예제를 재사용하다가 실패 시점에 가정을 발견합니다. 그렇다면 라이브러리 유지관리자들이 공식 계약이 몇 바이트로 표현할 수 있는 의미론의 사실상 수호자가 됩니다.

결과 지도이지 트랜잭션 로그가 아닙니다

최소한의 처방은 각 결과에 주소를 부여하는 것입니다. APNIC는 배열 이름과 항목 인덱스를 반환할 수 있습니다.create[0],update[2],delete[1]. 더 견고한 해법은 클라이언트가 각 작업에 불투명 키를 제공하도록 하고, 그 키를 그대로 돌려받는 것입니다. 이 키는 객체를 노출할 필요가 없으며 회원의 작업 내에서만 의미를 가질 수 있습니다.

이 상관관계와 함께, 한 행은 작업 계열과 안정적인 결과 코드를 표시할 수 있습니다. 안전한 경우 서버는 리소스 식별자나location을 첨부할 수 있습니다. 구조화된 문제 객체는 자유 텍스트를 대조 키로 만들지 않고도 실패를 설명할 수 있습니다. 한정된 지시—수정, 작업 조회, 상태 확인 또는 재시도—는 불필요한 반복을 줄입니다.

여러 작업이 하나의 트랜잭션을 공유한다면 소속과 결과는 그룹 수준에서 설명될 수 있습니다. 하나의 집합이 원자적일 때 다섯 개의 독립적 검증을 발명할 필요는 없습니다. 클라이언트가 어떤 작업이 같은 결정에 속하는지 아는 것만으로 충분합니다.

생성, 수정, 삭제, 알림을 섞은 예제와 함께 규범적 순서 규칙이 이미 진전입니다. 불투명 키는 부분 응답과 미래 변화에 더 잘 견딥니다. 기술적 선택은 APNIC에 속합니다. 실질적 요건은 단지 링크가 선언되고 검증 가능해야 한다는 것입니다.

스키마는 서비스의 일부입니다

레지스트리 API는 회원이 MyAPNIC에서 하던 작업을 자동화하도록 출시되었습니다. APNIC이 이 의존성을 장려하는 순간부터 OpenAPI 파일은 운영 표면이 됩니다. 생성된 클라이언트, 테스트, 복구 절차를 먹여 살립니다.

현재 문서에는 비동기성, 레이트 한도, 트랜잭션 자격, 피드백 경로를 명확히 밝히는 장점이 있습니다. 따라서 누락된 필드는 텅 빈 제품을 나타내지 않습니다. 사용자에게 있어 소프트웨어 인프라가 될 만큼 유용한 서비스의 전형적인 이음새를 드러낼 뿐입니다.

잘못된 반환을 증명할 때까지 기다릴 필요가 없습니다. 각 결과는 단지 자신이 답하는 질문을 지명할 수 있으면 됩니다. 그러면success,failure,notification은 운영자가 수동으로 자리를 맞추는 라벨이 아니라 실행 가능한 상태가 됩니다.

출처