회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반 번역문입니다. 윈도우, 리눅스 및 맥에서 HTTP (S)를 사용해 디버깅, 테스트 등의 오픈소스 도구를 제공하는 HTTP Toolkit 블로그에서 발행한 글입니다. 작가는 HTTP Toolkit을 만든 팀 페리(Tim Perry)로 그는 바르셀로나에서 일하고 있습니다. 본문은 HTTP의 새로운 메서드, HTTP 서치(SEARCH)에 대해 분석한 내용으로 다소 어려운 용어들은 각주를 통해 추가 설명을 해두었습니다. 꼼꼼히 읽어보시면 개발자분들에게 도움이 될만한 글입니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반 번역문입니다. 윈도우, 리눅스 및 맥에서 HTTP (S)를 사용해 디버깅, 테스트 등의 오픈소스 도구를 제공하는 HTTP Toolkit 블로그에서 발행한 글입니다. 작가는 HTTP Toolkit을 만든 팀 페리(Tim Perry)로 그는 바르셀로나에서 일하고 있습니다. 본문은 HTTP의 새로운 메서드, HTTP 서치(SEARCH)에 대해 분석한 내용으로 다소 어려운 용어들은 각주를 통해 추가 설명을 해두었습니다. 꼼꼼히 읽어보시면 개발자분들에게 도움이 될만한 글입니다.
HTTP는 하이퍼텍스트 전송 프로토콜(Hyper Text Transfer Protocol)을 줄여서 부르는 용어이며, 간단히 말하자면 인터넷의 서버와 클라이언트(단말) 사이에서 웹 문서를 주고받기 위해서 사용하는 규칙입니다. 이때 클라이언트가 보내는 요청의 종류를 메서드(method)라고 부릅니다. HTTP는 기본적으로 클라이언트가 요청(request)을 먼저 보내면, 서버가 그에 대해서 응답(response)하는 방식으로 통신이 이루어집니다. 따라서 (극히 예외적인 경우를 제외하면) 클라이언트가 보내는 건 전부 요청 메시지이고, 서버가 보내는 건 전부 응답 메시지라고 볼 수 있습니다.
HTTP의 메시지는 지정된 규칙(프로토콜)에 의해서 주고받으며, 각각의 메시지는 기본적으로 헤더(header, 본문의 앞에 추가되는 데이터)와 바디(body, 본문 데이터)로 구성됩니다. 따라서 클라이언트가 보내는 메시지는 요청 헤더(request header)와 요청 바디(request body)로 구성되고, 서버가 보내는 메시지는 응답 헤더(response header)와 응답 바디(response body)로 구성됩니다.
세상에 더 이상 고칠 필요 없이 완벽한 것은 없습니다. 그리고 HTTP도 예외는 아닙니다. HTTP의 서치(SEARCH)는 요청 바디(request body)를 포함해서 클라이언트의 요청을 안전하게 처리하기 위해 제안된 HTTP의 새로운 메서드입니다. 신규 메서드인 만큼 아직 초기 단계이고 계속 발전하고 있지만, 최근에 국제 인터넷 표준화 기구인 IETF가 SEARCH를 HTTP의 표준 메서드로 승인하기 위한 초안으로 채택했습니다. 따라서 이는 HTTP가 한층 더 발전할 수 있는 새롭고도 뛰어난 도구가 될 가능성이 있습니다.
이번 글에서는 이것이 무슨 의미인지, HTTP에 새로운 메서드가 왜 필요한지, 그리고 HTTP의 SEARCH는 어떻게 동작하는지에 대해서 알아보도록 하겠습니다.
현재 인터넷에서 사용되는 최신 API(응용프로그램 인터페이스)에서 볼 수 있는 HTTP의 주요한 메서드는 크게 다섯 가지가 있습니다. 각각의 메서드가 어떻게 동작하는지를 이해하려면, HTTP가 리소스를 위주로 정의되어 있다는 점을 기억할 필요가 있습니다. 리소스(resource)는 문서나 사진이 될 수도 있고, 또는 특정한 고객이나 고객 명단 전체를 말하는 것일 수도 있습니다. 이러한 리소스는 각자 고유한 URL을 가지고 있습니다. 예를 들어서, 고객 명단 전체를 의미하는 URL은 example.com/customers와 같이 표시될 수도 있고, 특정한 고객(예를 들어서 123번 고객)을 의미하는 URL은 example.com/customers/123와 같이 표시될 수 있습니다.
GET 메서드는 서버에게 어떤 리소스를 요청하는 것입니다. GET은 HTML 페이지를 요청하거나, 어떤 API를 통해서 데이터를 읽거나, 이미지를 로딩하기 위해서 자주 사용되는 메서드입니다.
GET은 ‘안전한’ 요청을 위한 메서드이기 때문에, 순수하게 데이터를 읽기만 합니다. 즉, 서버의 상태를 바꿀 수도 없고, 다른 부작용이 있어서도 안 됩니다. 그리고 GET 메서드에 대한 응답은 캐시(cache) 서버가 담당하는 경우가 많습니다. (쉽게 설명하자면, 대부분의 클라이언트가 받는 GET 메서드에 대한 응답은 중앙의 실제 서버가 아니라 클라이언트에 가까운 곳에 별도로 구축해 놓은 캐시 서버에서 온다는 것입니다.)
GET 요청을 보낼 때는 클라이언트에서 필요한 매개변수(parameter)[1]를 URL에 포함시킬 수 있습니다. GET 메서드에서는 리소스에 대한 경로(URL)에 질의 매개변수(query parameter)를 추가할 수 있지만, 일반적으로 요청 바디는 갖고 있지 않습니다. 사실 요청 바디를 금지하고 있는 것은 아니지만, 실제로는 아무런 쓸모가 없습니다. 그래서 대부분의 서버에서는 클라이언트에서 GET 메서드에 포함시켜서 보내는 바디는 무시하거나 아예 전송을 거부하는 경우가 많습니다.
GET 메서드에서는 Accept, Accept-Language, Accept-Encoding이라는 헤더를 사용할 수 있는데, 이들은 각각 클라이언트가 이해할 수 있는 콘텐츠 타입이 무엇인지, 클라이언트가 이해할 수 있는 언어가 무엇인지, 클라이언트가 이해할 수 있는 인코딩(encoding, 부호화) 방식이 무엇인지를 서버에게 알려주는 항목입니다. (예를 들자면, ‘123번 고객의 정보를 XML을 문서의 형태로 주세요’라고 요청하는 것입니다.) 그리고 Range 헤더를 이용하면 문서 중에서 원하는 부분만 요청할 수 있습니다. (예를 들자면, ‘24번 동영상 파일에서 맨 앞부분에 있는 100바이트의 정보만 주세요’라고 요청하는 것입니다.)
POST 메서드는 클라이언트에서 서버로 데이터를 보내고, 서버에서 그 데이터를 처리해 달라고 요청하는 것입니다. 이는 “무엇을 해주세요”라고 요청하는 상당히 일반적인 메서드입니다. 그래서 메시지를 전송하거나, (새로운 고객 정보와 같은) 신규 리소스를 생성하거나, 클라이언트에 입력된 데이터를 처리하는 프로세스를 서버 측에서 실행하기 위해서 자주 사용됩니다.
GET 메서드와 마찬가지로 URL이나 다양한 헤더를 통해서 매개변수를 전달할 수 있지만, 다른 점이라면 요청 바디를 가질 수 있다는 것입니다. 서버에서 처리해야 하는 데이터를 바디에 포함시켜서 전달해야 하기 때문입니다. 서버가 데이터를 처리하는 걸 돕기 위해서, 바디에 있는 데이터의 구체적인 유형이 무엇인지에 대해서 Content-Type이라는 헤더에 명시해 놓을 수 있습니다. (예, Content-Type: application/json)
얼핏 봐서도 알 수 있듯이, 안전한 메서드는 아닙니다. POST 메서드는 서버의 상태를 변경할 수 있으며, 다른 곳에서 부작용을 일으킬 수도 있습니다. 그렇기 때문에 이 메서드는 캐시로 처리를 할 수 없는 경우가 거의 대부분인데, 실제로는 캐시를 부정하는 쪽에 가깝습니다. 즉, 어떤 리소스를 요청하는 POST 메서드가 클라이언트에서 외부로 나가는 것을 콘텐츠 전송 네트워크(CDN)나 브라우저가 감지하면, 이들은 기존에 캐시 서버에 저장되어 있던 해당하는 리소스에 대한 데이터를 전부 무효화하고 삭제합니다.
PUT 메서드도클라이언트에서 서버로 데이터를 보내고, 서버에서 그 데이터를 활용해서 새로운 리소스를 만들거나 기존의 리소스를 교체하라고 요청하는 것입니다. POST와 비슷하지만, PUT이 훨씬 구체적입니다. 즉, POST 메서드는 비교적 좀 더 다양한 용도로 사용할 수 있지만, PUT은 요청 메시지의 바디에 명시된 내용과 일치하는 명령을 생성하거나 업데이트하기 위해서만 사용됩니다.
일반적으로 API에서는 어떤 데이터에 대한 작업들 중에서도 특별히 생성이나 업데이트 명령을 수행하기 위해서 PUT 메서드를 사용합니다. (반면에 POST는 해당 데이터에 대해서 좀 더 다양한 명령을 실행하기 위해서 사용될 수 있습니다.) POST와 마찬가지로, PUT 메서드도 요청 바디를 포함할 수 있고, 서버의 상태에도 영향을 미칠 수 있지만(즉, 캐시 서버에 있는 데이터를 무효화할 수 있습니다), 부작용은 없습니다. 그 대신에 PUT 메서드는 멱등성(idempotent)[2]을 가져야 합니다. 즉, 완전히 동일한 PUT 요청을 두 번 전송한다고 하더라도 결과는 달라지지 않으며, 요청을 한 번 전송한 것과 동일한 상태를 유지해야 한다는 것입니다.
POST의 document 명령과 PUT의 document 명령을 비교해 보면, 차이점을 좀 더 명확하게 알 수 있습니다. POST의 document는 일반적으로 ‘새로운 문서를 생성한다’는 것을 의미하며, 이런 명령을 요청할 때마다 매번 새로운 문서가 만들어집니다. 그러나 PUT의 document는 ‘새로운 문서를 생성하거나, 기존의 문서 전체에서 해당하는 항목을 클라이언트가 전달하는 데이터로 교체한다’는 것을 의미합니다. 서버가 이러한 요청을 허용하기는 하지만, 클라이언트에서 동일한 요청을 반복해서 전송하더라도 서버에서는 요청이 한 번만 이루어진 것으로 판단해서 동일한 상태를 유지합니다.
PATCH 메서드는 클라이언트에서 서버로 데이터를 보내고, 서버에서 그 데이터를 사용해서 리소스의 일부를 업데이트하라고 요청하는 것입니다. PATCH는 고객의 주소를 업데이트하거나, 텍스트 문서의 일부를 수정하는 작업에 사용할 수 있습니다. PUT이나 POST와 마찬가지로, PATCH에서도 요청 바디를 가질 수 있습니다. 그러나 안전한 요청이 아니며, PUT처럼 멱등성을 갖는 것도 아닙니다. (즉, 어떤 문서에 대해서 동일한 수정 명령을 두 번 요청하면, 문서는 두 차례 수정됩니다.)
DELETE 메서드는 서버에 리소스를 삭제하라고 요청하는 것입니다. 다른 메서드와는 다르게, DELETE에 대해서는 굳이 따로 설명하지 않아도 될 것 같습니다. 한 가지 중요한 것은, GET과 마찬가지로 DELETE 메서드도 바디를 가질 수 없다는 것입니다. 데이터를 삭제하면서 굳이 다른 데이터를 전송할 필요가 없기 때문입니다. 그래서 서버에서는 DELETE 요청 메시지에 바디가 포함되어 있다면 그것을 무시하거나 거부할 수 있는 권한이 있습니다.
그 외에도 HTTP에서 많이 사용되는 메서드들은 다음과 같습니다.
이런 메서드들은 모두 아주 중요한 것이긴 하지만, 지금 이 글에서 관심 있는 주제는 아닙니다. 따라서, 이해가 잘 안 되었더라도 크게 상관은 없습니다.
GET은 데이터를 얻기 위해서, POST는 안전하지 않은 여러 동작을 수행하기 위해서, PUT은 멱등성(idempotent)을 가지며 전체적인 업데이트를 수행하기 위해서, PATCH는 부분적인 업데이트를 수행하기 위해서, DELETE는 데이터를 삭제하기 위해서 사용합니다. GET과 DELETE 이외의 나머지 메서드는 모두 요청 메시지에서 바디(body, 본문)를 가질 수 있습니다.
이런 메서드들 사이의 차이점은 중요한 의미를 갖고 있습니다. 캐시(cache) 서버는 거의 대부분의 애플리케이션에서 아주 중요하며, 요청을 안전하게 구현하는 것은 UX에서 필수적이라고 할 수 있기 때문에, 각각의 상황에서 사용할 수 있는 메서드와 그럴 수 없는 메서드가 있기 때문입니다. 그리고 이러한 메서드는 여러분이 만든 API의 작동 원리를 다른 사람들에게 설명하기 위한 기본적인 토대의 역할도 합니다. 아무튼 이런 HTTP는 우리가 모두가 사용하고 있는 수많은 인터넷 인프라를 뒷받침하고 있는 중요하면서도 기본적인 규약(프로토콜)입니다. 따라서 적절한 용도에 적절한 메서드를 사용하는 것이 중요합니다.
사실 기존의 메서드도 상당히 괜찮기는 하지만, 몇 가지 아쉬운 부분이 있습니다. 예를 들어서 복잡한 데이터를 검색한다고 해 보겠습니다. 그러려면 당연히 서버 쪽으로 보내야 하는 데이터도 많은 것입니다. 하지만 서버의 상태는 변경하고 싶지 않다면 어떻게 해야 할까요?
기본의 메서드로 할 수 있는 방법은 두 가지가 있습니다.
그런데 둘 다 그다지 좋은 방법은 아닙니다.
왜냐하면 URL의 길이에는 제한이 있으며, 헤더의 크기에 대해서 HTTP 표준에서는 별도의 제한을 두고 있지는 않지만 상용으로 출시된 웹 서버에서는 제한을 두고 있는데, 그 값이 전부 제각각입니다. 따라서 URL에서 특수 문자나 줄 바뀜 등이 발생할 경우에는 별도로 부호화를 해야 하기 때문에, URL 자체만 읽었을 때는 도무지 무슨 의미인지를 알 수가 없게 됩니다. 그렇다고 해서 그렇게 복잡한 URL을 해석하는 걸 도와주는 별도의 정보를 넣어 놓을 수도 없으며, 이러한 작업을 좀 더 쉽게 도와줄 수 있는 도구도 사실상 찾아볼 수 없습니다. 그렇기 때문에 필요한 쿼리(query, 질의)를 전부 모아서 문자열을 만드는 작업은 여러분 혼자서 직접 해야 합니다. 굳이 이렇게까지 해야 할 필요가 있을까요?
그리고 인터넷의 구조에서 캐시는 아주 중요한 기능이지만, POST를 이용하면 그 모든 게 완전히 무효화됩니다. 그리고 POST 메서드를 이용해서 이러한 요청을 처리하면 근본적인 문제가 있습니다. 왜냐하면 단순히 검색 요청을 했을 뿐이기 때문에 서버에는 어떠한 상태도 변경하지 않아야 하고, 어떠한 부작용도 일으키지 않아야 하겠지만, 실제로는 마치 이 요청이 무슨 문제라도 일으킬 가능성이 있는 것처럼 관련된 모든 캐시를 삭제해 버리기 때문입니다.
그리고 복잡한 쿼리를 전송하려고 하는 리소스의 종류와, 데이터를 보내려고 하는 리소스의 종류는 동일한 것입니다. 그렇다면 과연 POST 메서드를 통해서 새로운 고객에 대한 항목을 생성하라는 명령을 보내면서, 동시에 고객에 대한 정보를 요청하는 쿼리를 전송할 수 있을까요? 물론 POST 메서드로도 가능하긴 하지만, 동일한 리소스에 대해서 여러 번에 걸쳐서 요청을 해야 합니다. 따라서 작업 시간이 오래 걸리고 복잡한 소프트웨어가 될 가능성이 높습니다. 다행히도, HTTP는 지금도 계속해서 발전하고 있는 표준이기 때문에, 이런 문제들을 충분히 개선할 수 있습니다.
이러한 문제를 해결하기 위해서 새롭게 제안된 메서드가 바로 SEARCH입니다. SEARCH 메서드는 (대상 리소스를 변경하지 않는) 안전한 요청이며, 바디(body)도 포함할 수 있습니다. 위에서 예로 든 경우에 SEARCH를 이용해서 구현한다면 우리는 매개변수를 모두 URL에 부호화해서 집어넣어야 한다거나, POST 메서드를 이용할 필요가 없습니다. 그러지 않고도 복잡한 데이터의 쿼리를 정확하게 전송할 수 있습니다.
그런데 이 메서드는 아직까지 정식 표준은 아닙니다. 세부적인 내용들은 변경될 수 있으며, SEARCH라는 이름조차도 아직 확정된 것은 아닙니다. 아직 임시이기는 하지만 현재까지의 정식 명칭은 SEARCH가 아니라 “바디를 가진 안전한 메서드(safe method with body)”이기 때문에 얼마든지 바뀔 가능성이 있습니다.) 따라서 이런 점들을 잘 감안해서 살펴봐야 하긴 하지만, 2021년 3월에 IETF는 SEARCH를 HTTP의 임시 규격으로 승인했습니다. 따라서 별 문제가 없다면, 결국엔 정식 표준으로 받아들여지게 될 것입니다.
현재 시점에서의 SEARCH 메서드를 활용한 HTTP 요청은 다음과 같은 형태입니다.
(물론 이것은 하나의 예시일 뿐이며, 원격 클라이언트가 서버 쪽으로 이렇게 SQL 쿼리를 함부로 보내도록 허용해서는 안 됩니다. 그렇지만 대략적인 형태는 이해하실 수 있을 것입니다.)
현재의 규격에서는 이러한 쿼리에 대한 응답을 캐시에서 처리할 수 있도록 정의하고 있지는 않습니다. 왜 그런지 정확히 알 수는 없지만, 저는 그 이유가 현재의 캐시 서버들이 메시지의 바디를 고려하지 않기 때문이라고 생각합니다. 만약에 이러한 쿼리를 캐시에서 처리할 수 있게 하려면 이와 관련하여 별도의 논의와 평가가 필요할 정도로 상당한 변화가 될 것입니다.
즉, SEARCH 메서드는 POST처럼 캐시를 무효화하고 있지는 않습니다. 만약 위의 예제와 동일한 요청을 POST로 대체한다면 모든 데이터를 서버로부터 전부 다시 다운로드해야 합니다. 왜냐하면 POST 메서드는 서버까지 도달하는 경로에 있는 모든 캐시를 찾아서 그 데이터를 삭제할 것이기 때문입니다. SEARCH는 그렇게 하지 않기 때문에, 그 자체만으로도 수많은 캐시 서버의 설정에 있어서 아주 많은 도움이 될 것입니다.
따라서, SEARCH가 가진 장점은 다음과 같습니다.
SEARCH를 이용하면 그래프QL(GraphQL)에서부터 일반 SQL은 물론이고 오픈데이터 프로토콜(OData)에 이르기까지 다양한 환경에서도 복잡한 쿼리를 지원할 수 있습니다. 물론 클라이언트가 사용하는 쿼리 언어가 무엇인지를 서버가 알아야 하지만, 그런 문제는 요청 메시지의 헤더에서 Content-Type으로 명시해 놓으면 아주 쉽게 해결할 수 있습니다.
SEARCH는 특히 GraphQL을 사용할 때 더욱 흥미롭습니다. GraphQL은 GET 메서드와 POST 메서드를 모두 지원하고 있지만 그로 인해서 겪는 곤란한 점들이 있기 때문에, 위에서 살펴본 문제점들에 딱 들어맞는 사례라고 할 수 있습니다. GraphQL을 이용한 읽기 전용 요청에서 SEARCH 메서드를 이용한다면 UX를 상당히 개선할 수 있으며, 향후의 캐시 처리와 같은 HTTP의 자체적인 기능과 GraphQL을 더욱 잘 연동되게 해 줄 것입니다.
이러한 쿼리 언어는 가장 대표적인 사례이긴 하지만, SEARCH는 그 외에도 훨씬 더 많은 부분에서 사용할 수 있습니다. 왜냐하면 서버로부터 데이터를 요청하기 위해서 메시지를 보내기 위한 기능을 전부 지원하면서도 부작용은 없기 때문입니다.
여기에 더해서 SEARCH 메서드에는 Accept-Search라는 헤더가 있습니다. 이 헤더는 응답 메시지에서 사용되는데, 그 모습은 아래와 같습니다.
이 헤더는 클라이언트가 보낸 SEARCH 요청을 서버가 수락(accept)했음을 알리는 것이며, 앞으로 서버가 받을 수 있는 쿼리의 형식들을 알려줍니다. 이는 기존의 Accept-Patch 헤더와 비슷합니다.
서버는 이 헤더를 어떠한 응답 메시지에서도 포함시킬 수 있지만, 특히 옵션(OPTIONS) 메서드에 대한 응답에서 유용하게 쓰일 수 있습니다. 왜냐하면 OPTIONS는 서버에 있는 리소스가 어떤 특성을 지원하는지를 클라이언트 쪽에서 물어보는 메서드이기 때문입니다.
개인적으로 SEARCH는 상당한 진전이라고 생각하지만, 현재로서는 다소 오해를 불러일으킬 수도 있고 개선의 여지가 있는 부분이 있어서 주의가 필요합니다.
이에 대한 표준은 웹 분산 저작 및 버전 관리(WebDAV)에 있는 SEARCH 메서드를 기반에 두고 있습니다. (WebDAV는 HTTP를 뒷받침하는 일종의 확장 버전이라고 할 수 있으며, 웹에서의 문서 작성 및 버전 관리를 위해 만들어진 통신 프로토콜입니다.)
여기에는 장점과 단점이 있습니다. 장점이라면, 비슷한 메서드가 이미 예전부터 존재해 왔기 때문에, HTTP 툴킷(HTTP Toolkit) 그 자체는 물론이고 수많은 프록시 서버나 CDN 등의 인프라가 이미 그 메서드를 지원하고 있기 때문에, SEARCH 메서드가 거의 아무런 문제없이 금세 받아들여질 수 있다는 것입니다. 반면에, WebDAV에 지장을 주지 않으면서 HTTP에 SEARCH를 추가하기 위해서는 호환성이라는 문제를 고려해야 합니다. 현재로서의 해결 방법은 content-type 헤더에 application/xml나 text/xml을 포함하고 있는 모든 요청이 WebDAV에서 정하고 있는 쿼리 바디에 대한 규격을 따르는 것입니다.
그렇지 않다면 WebDAV 규격에 맞지 않는 요청의 형식이기 때문에, 서버에서는 이를 무시할 것입니다. 따라서 XML API에서 SEARCH 기능을 실행할 경우에는 실제로 문제가 발생할 수 있습니다. 향후에는 XML 형식에 대해서만 적용되는 이러한 제약사항이 완화될 수 있지만, 현재로서는 아직까지는 규격 내부에 정식으로 정해져 있지는 않습니다.
캐시를 무효화하지 않는 것은 좋은 시도이지만, 그렇다고 해서 SEARCH 요청의 결과를 캐시로 저장할 수 있는 것은 아닙니다. 이는 이 메서드가 기본적으로 캐시를 위한 수단이 없다는 의미가 아닙니다. 설령 캐시를 위한 헤더를 갖고 있더라도 캐시를 할 수 없다는 뜻입니다. GET 메서드와 비교하면 이 점은 분명한 제약사항이기도 하고, 쿼리의 결과를 캐시로 저장하는 것은 상당히 일반적으로 쓰이는 기능이기 때문에 이는 상당히 아쉬운 부분입니다.
현재 SEARCH를 캐시로 저장할 수 있는 조건을 정확하게 규정하기 위한 작업이 진행 중에 있기 때문에, 실제 표준으로 지정된다면 훨씬 더 개선될 될 것으로 보입니다. 제 생각으로는 캐시를 SEARCH 메서드의 기본적인 속성으로 만들기보다는, 아마도 관련된 헤더를 추가할 가능성이 커 보입니다. 그렇지만 아직은 구체적으로 정해진 것이 없기 때문에, 좀 더 지켜봐야 할 것 같습니다.
SEARCH라는 명칭은 그다지 좋은 이름이 아닙니다. 모든 쿼리가 검색(search)을 위한 것도 아니며, 현재로서의 정식 명칭인 “바디를 가진 안전한 메서드(safe method with body)”에도 위에서 논의한 것처럼 단순히 데이터에 대한 질의를 완전히 넘어서는 다른 수많은 용도가 있을 것이기 때문입니다. 이러한 문제에 대해서는 이미 논의하고 있으며, QUERY나 FETCH와 같은 명칭이 제안되기도 했습니다. 그리고 SEARCH라는 명칭은 이미 WebDAV에서 사용하고 있어서 호환성의 측면에서는 분명한 장점이 있기 때문에, 그런 부분에 대해서도 고려를 해야 할 것입니다.
만약에 이름을 다른 것으로 바꾼다면 기존의 모든 소프트웨어에서는 채택 속도가 그렇게 빠르지는 않을 것입니다. 그러나 새롭게 바뀐 이름이 개발자들이 보기에도 의미가 더욱 명확하거나 사용하기 쉬울 수도 있습니다. 불행히도 간단한 문제는 아닌 것 같습니다.
개인적으로 저는 SEARCH가 몇 가지의 주의사항이 있음에도 불구하고 지금의 모습만으로도 이미 충분한 가치가 있다고 생각합니다. 그리고 기존의 HTTP 표준을 더욱 빠르게 개선할 수 있는 좋은 점들이 있다고 봅니다. 만약 SEARCH 메서드에 대해서 더욱 자세히 알고 싶으시다면, 현재까지의 내용에 대해서는 IEFT의 웹사이트[6]에서 확인하실 수 있습니다. 그리고 IETF에서 HTTP와 관련한 업무를 담당하는 실무 그룹(HTTP Working Group)의 메일링 리스트[7]에 등록하시거나 그들이 운영하는 깃허브(GitHub)의 리포지터리(repository)[8]에서 관련한 내용을 직접 확인하실 수 있습니다. (이곳에는 SERACH 메서드를 포함해서 향후에 HTTP에 추가될 수 있는 내용들에 대한 다양한 자료들이 모여 있습니다.) 관련 자료들을 살펴보시고 HTTP의 미래를 만들기 위한 여러분의 생각을 공유해주셔도 좋겠습니다.
[1] 컴퓨터 프로그래밍에서 어떤 함수(function)에 입력하는 변수
[2] 동일한 요청을 여러 번 반복해도 그 결과가 언제나 동일한 성질
[3] 출처가 다른 리소스를 다른 곳에서 요청해서 사용할 수 있게 허용하는 구조
[4] 클라이언트와 서버를 중간에서 중계하는 역할을 하는 서버
[5] 클라이언트와 서버 사이를 안전하게 중계하는 역할을 하는 통로
[6] https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/?include_text=1
[7] https://lists.w3.org/Archives/Public/ietf-http-wg/
[8] https://github.com/httpwg/http-extensions/
> 이 글은 'Defining a new HTTP method: HTTP SEARCH'을 각색하여 작성되었습니다.
좋아요
댓글
공유
공유
5.2K
