확인 상태를 돌려받았는데 출처는 이전 값이었다. K-POP PULSE의 실제 요청 기록은 한국 시간 9월 30일에 있고, 10월 1일 운영 문서는 이 함정을 추가로 적었다. 문서에 적힌 날짜와 실제 요청의 시점을 나누어 읽었다.
첫 요청은 출처 필드 앞에 new_를 붙였고 당시 통로는 그 이름을 처리하지 않았다. 이어서 지원하는 이름으로 다시 요청한 출력은 같은 확인 상태였지만 저장된 출처는 새 값이었다. 나는 응답의 낱말과 실제 바뀌어야 할 값을 따로 확인하는 이야기를 남기려 한다.
비슷한 필드 이름이 같은 계약은 아니었다
당시 수정 통로에는 일부 필드의 이름 앞에 new_가 붙고 다른 필드는 원래 이름을 그대로 사용하는 계약이 있었다. 익숙한 모양을 따라 출처에도 같은 접두어를 붙이면 맞아 보일 수 있지만 지원하는 필드는 아니었다. 코드를 읽은 결과도 처리할 이름의 목록을 보여 준다.
나는 다른 홈페이지의 API를 사용할 때 이름을 추정해서 보내지 않으려 한다. 대상 레코드를 지정하는 값과 바꿀 값을 구별하고, 현재 지원하는 계약을 읽는다. 필드를 알아보기 좋은 이름으로 만들었다는 사실과 서버가 그 필드를 처리한다는 사실은 다르다.
첫 응답과 저장 후 읽기는 서로 다른 말을 했다
실제 첫 출력은 두 일정의 확인 상태와 식별자를 반환했다. 그러나 같은 실행에서 읽은 출처는 이전 값이었다. 응답에 오류가 없다고 요청한 모든 필드가 반영되었다는 결론을 내릴 수 없는 구체적인 사례다.
후속 요청은 올바른 출처 필드와 위치 정보를 보냈다. 돌아온 상태는 역시 확인이었고, 다음 읽기에서는 기대한 새 출처와 위치가 보였다. 같은 낱말의 응답 두 개를 저장값의 차이와 나란히 놓으면 무엇을 확인해야 했는지 분명해진다.
현재도 같은 결함이라고 단정하지 않는다
이번 근거는 당시 요청 조각과 실제 읽기 결과, 그때 통로 코드와 문서다. 지금 원본 API를 새로 호출해 결함을 검사하거나 그 서버를 수정한 결과는 아니다. 옛 문제를 현재의 모든 수정 통로가 가진다고 일반화하지 않는다.
다른 사이트를 만든다면 지원하지 않는 필드를 어떻게 거부할지, 요청한 변경과 저장 결과를 무엇으로 확인할지 계약으로 정한다. 성공 응답을 더 자세히 만드는 방법과 별도의 읽기를 제공하는 방법도 각 서비스의 책임에 맞춰 검토할 수 있다. 설계 제안과 적용 완료를 나눈다.
다시 요청하기 전에 무엇이 저장됐는지 읽는다
이 사건은 지원하는 필드로 요청을 고치는 문제였지만 응답을 읽지 못한 경우에는 상황이 다를 수 있다. 요청이 처리되었는지 모르는 상태에서 같은 쓰기를 보내면 중복이나 충돌이 생길 수 있다. 나는 확인 응답과 저장값, 불확실한 관측을 다른 결과로 남기려 한다.
아래는 그 책임을 설명하는 새 지도다. 원본 API 호출 코드나 서버 패치가 아니다. 실제 요청 대상과 바뀌어야 할 필드를 정하고, 같은 레코드를 다시 읽을 조건을 연결한다. 어떤 값이 정답인지와 읽기가 최신인지는 그 사이트에서 확인해야 한다.
코드와 구현 살펴보기
새 설명용 요청·읽기 검토 지도. 원본 API 실행이나 수정이 아니다.
{
"request": "the supported field the task intends to change",
"receipt": "acknowledgement only; not complete stored-value proof",
"readback": "inspect the same record and expected field",
"next_action": "correct the contract or obtain missing evidence"
}
// New review map. It does not send a request or patch the old API.기대한 필드와 읽은 값을 나누는 코드를 만든다
이번 공유 프로그램은 명시한 예상 필드와 공급한 읽기 결과만 비교한다. 값이 같으면 일치, 다른 값이면 불일치, 읽기나 필드가 없으면 검사불가로 남긴다. 미확인을 빈값으로 채워 성공으로 만들지 않으며, 종류와 중첩 값의 비교 조건도 명시한다.
새 합성 입력과 실제 CLI의 26개 검사를 통과했고 ZIP에 코드와 예제, 검사와 설명을 넣었다. 실제 API를 호출하거나 쓰기와 재시도를 하지 않는 새 구현이다. 출처가 올바른 읽기인지, 어떤 필드를 비교해야 하는지는 호출자가 공급해야 한다. 원본 결함을 고친 프로그램으로 소개하지 않는다.
성공이라는 말의 범위를 실제 값으로 좁힌다
홈페이지를 관리할 AI에게 필요한 것은 편한 쓰기 명령뿐 아니라 그 결과를 읽는 방법이었다. 출처를 바꾸라고 시켰으면 출처를 확인하고, 제목을 고쳤으면 제목을 읽는다. 작업자가 다음에 무엇을 해야 하는지 결과가 알려 줄 수 있어야 한다.
나는 두 번의 같은 상태 응답과 서로 다른 저장값을 함께 공개한다. 이 전후가 있어야 초보 제작자도 응답의 성공과 원하는 변화가 같은 일이 아니라는 뜻을 이해할 수 있다. 프로그램을 편리하게 연결할수록 확인할 값의 의미를 남기는 일이 더 중요해졌다.