다른 서비스
NEW
기획
디자인
개발
프로덕트
아웃소싱
프리랜싱
비즈니스
최근 검색어
전체 삭제
최근 검색어가 없습니다.

개발

HTTP의 새로운 메서드, 서치(SEARCH)에 대하여

본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반 번역문입니다. 윈도우, 리눅스 및 맥에서 HTTP (S)를 사용해 디버깅, 테스트 등의 오픈소스 도구를 제공하는 HTTP Toolkit 블로그에서 발행한 글입니다. 작가는 HTTP Toolkit을 만든 팀 페리(Tim Perry)로 그는 바르셀로나에서 일하고 있습니다. 본문은 HTTP의 새로운 메서드, HTTP 서치(SEARCH)에 대해 분석한 내용으로 다소 어려운 용어들은 각주를 통해 추가 설명을 해두었습니다. 꼼꼼히 읽어보시면 개발자분들에게 도움이 될만한 글입니다.

 

*HTTP는 무엇인가요?

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는 어떻게 동작하는지에 대해서 알아보도록 하겠습니다.

 

 

현재 HTTP의 메서드

현재 인터넷에서 사용되는 최신 API(응용프로그램 인터페이스)에서 볼 수 있는 HTTP의 주요한 메서드는 크게 다섯 가지가 있습니다. 각각의 메서드가 어떻게 동작하는지를 이해하려면, HTTP가 리소스를 위주로 정의되어 있다는 점을 기억할 필요가 있습니다. 리소스(resource)는 문서나 사진이 될 수도 있고, 또는 특정한 고객이나 고객 명단 전체를 말하는 것일 수도 있습니다. 이러한 리소스는 각자 고유한 URL을 가지고 있습니다. 예를 들어서, 고객 명단 전체를 의미하는 URL은 example.com/customers와 같이 표시될 수도 있고, 특정한 고객(예를 들어서 123번 고객)을 의미하는 URL은 example.com/customers/123와 같이 표시될 수 있습니다.

 

 

겟(GET)

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)

POST 메서드는 클라이언트에서 서버로 데이터를 보내고, 서버에서 그 데이터를 처리해 달라고 요청하는 것입니다. 이는 “무엇을 해주세요”라고 요청하는 상당히 일반적인 메서드입니다. 그래서 메시지를 전송하거나, (새로운 고객 정보와 같은) 신규 리소스를 생성하거나, 클라이언트에 입력된 데이터를 처리하는 프로세스를 서버 측에서 실행하기 위해서 자주 사용됩니다.

 

GET 메서드와 마찬가지로 URL이나 다양한 헤더를 통해서 매개변수를 전달할 수 있지만, 다른 점이라면 요청 바디를 가질 수 있다는 것입니다. 서버에서 처리해야 하는 데이터를 바디에 포함시켜서 전달해야 하기 때문입니다. 서버가 데이터를 처리하는 걸 돕기 위해서, 바디에 있는 데이터의 구체적인 유형이 무엇인지에 대해서 Content-Type이라는 헤더에 명시해 놓을 수 있습니다. (예, Content-Type: application/json)

 

얼핏 봐서도 알 수 있듯이, 안전한 메서드는 아닙니다. POST 메서드는 서버의 상태를 변경할 수 있으며, 다른 곳에서 부작용을 일으킬 수도 있습니다. 그렇기 때문에 이 메서드는 캐시로 처리를 할 수 없는 경우가 거의 대부분인데, 실제로는 캐시를 부정하는 쪽에 가깝습니다. 즉, 어떤 리소스를 요청하는 POST 메서드가 클라이언트에서 외부로 나가는 것을 콘텐츠 전송 네트워크(CDN)나 브라우저가 감지하면, 이들은 기존에 캐시 서버에 저장되어 있던 해당하는 리소스에 대한 데이터를 전부 무효화하고 삭제합니다.

 

 

풋(PUT)

PUT 메서드도클라이언트에서 서버로 데이터를 보내고, 서버에서 그 데이터를 활용해서 새로운 리소스를 만들거나 기존의 리소스를 교체하라고 요청하는 것입니다. POST와 비슷하지만, PUT이 훨씬 구체적입니다. 즉, POST 메서드는 비교적 좀 더 다양한 용도로 사용할 수 있지만, PUT은 요청 메시지의 바디에 명시된 내용과 일치하는 명령을 생성하거나 업데이트하기 위해서만 사용됩니다.

 

일반적으로 API에서는 어떤 데이터에 대한 작업들 중에서도 특별히 생성이나 업데이트 명령을 수행하기 위해서 PUT 메서드를 사용합니다. (반면에 POST는 해당 데이터에 대해서 좀 더 다양한 명령을 실행하기 위해서 사용될 수 있습니다.) POST와 마찬가지로, PUT 메서드도 요청 바디를 포함할 수 있고, 서버의 상태에도 영향을 미칠 수 있지만(즉, 캐시 서버에 있는 데이터를 무효화할 수 있습니다), 부작용은 없습니다. 그 대신에 PUT 메서드는 멱등성(idempotent)[2]을 가져야 합니다. 즉, 완전히 동일한 PUT 요청을 두 번 전송한다고 하더라도 결과는 달라지지 않으며, 요청을 한 번 전송한 것과 동일한 상태를 유지해야 한다는 것입니다.

 

POST의 document 명령과 PUT의 document 명령을 비교해 보면, 차이점을 좀 더 명확하게 알 수 있습니다. POST의 document는 일반적으로 ‘새로운 문서를 생성한다’는 것을 의미하며, 이런 명령을 요청할 때마다 매번 새로운 문서가 만들어집니다. 그러나 PUT의 document는 ‘새로운 문서를 생성하거나, 기존의 문서 전체에서 해당하는 항목을 클라이언트가 전달하는 데이터로 교체한다’는 것을 의미합니다. 서버가 이러한 요청을 허용하기는 하지만, 클라이언트에서 동일한 요청을 반복해서 전송하더라도 서버에서는 요청이 한 번만 이루어진 것으로 판단해서 동일한 상태를 유지합니다.

 

 

패치(PATCH)

PATCH 메서드는 클라이언트에서 서버로 데이터를 보내고, 서버에서 그 데이터를 사용해서 리소스의 일부를 업데이트하라고 요청하는 것입니다. PATCH는 고객의 주소를 업데이트하거나, 텍스트 문서의 일부를 수정하는 작업에 사용할 수 있습니다. PUT이나 POST와 마찬가지로, PATCH에서도 요청 바디를 가질 수 있습니다. 그러나 안전한 요청이 아니며, PUT처럼 멱등성을 갖는 것도 아닙니다. (즉, 어떤 문서에 대해서 동일한 수정 명령을 두 번 요청하면, 문서는 두 차례 수정됩니다.)

 

 

딜리트(DELETE)

DELETE 메서드는 서버에 리소스를 삭제하라고 요청하는 것입니다. 다른 메서드와는 다르게, DELETE에 대해서는 굳이 따로 설명하지 않아도 될 것 같습니다. 한 가지 중요한 것은, GET과 마찬가지로 DELETE 메서드도 바디를 가질 수 없다는 것입니다. 데이터를 삭제하면서 굳이 다른 데이터를 전송할 필요가 없기 때문입니다. 그래서 서버에서는 DELETE 요청 메시지에 바디가 포함되어 있다면 그것을 무시하거나 거부할 수 있는 권한이 있습니다.

 

 

그 외의 메서드

그 외에도 HTTP에서 많이 사용되는 메서드들은 다음과 같습니다.

  • 헤드(HEAD): GET과 마찬가지로 바디가 없으며, GET 메서드를 요청했을 때 돌아올 응답 메시지의 헤더를 요청하는 것입니다.
  • 옵션(OPTIONS): 다른 메서드를 전송하는 방법에 대한 정보를 요청하는 메서드인데, 주로 브라우저에서 교차 출처 리소스 공유(CORS)[3]를 위해서 사용합니다.
  • 커넥트(CONNECT): 프록시(proxy)[4]용도로 사용되는 다른 서버로 연결되는 터널(tunnel)[5]을 요청합니다.
  • 트레이스(TRACE): 클라이언트에서 전송한 메시지를 그대로 되돌려주는 에코(echo, 반향)를 요청하는 것으로, 일반적으로 프록시 서버나 CDN 등을 거치면서 메시지의 변경 여부를 확인하기 위해서 사용됩니다. (그러나 실제로 사용되거나 지원되는 경우는 많지 않습니다.)

 

이런 메서드들은 모두 아주 중요한 것이긴 하지만, 지금 이 글에서 관심 있는 주제는 아닙니다. 따라서, 이해가 잘 안 되었더라도 크게 상관은 없습니다.

 

 

중간 요약

GET은 데이터를 얻기 위해서, POST는 안전하지 않은 여러 동작을 수행하기 위해서, PUT은 멱등성(idempotent)을 가지며 전체적인 업데이트를 수행하기 위해서, PATCH는 부분적인 업데이트를 수행하기 위해서, DELETE는 데이터를 삭제하기 위해서 사용합니다. GET과 DELETE 이외의 나머지 메서드는 모두 요청 메시지에서 바디(body, 본문)를 가질 수 있습니다.

 

이런 메서드들 사이의 차이점은 중요한 의미를 갖고 있습니다. 캐시(cache) 서버는 거의 대부분의 애플리케이션에서 아주 중요하며, 요청을 안전하게 구현하는 것은 UX에서 필수적이라고 할 수 있기 때문에, 각각의 상황에서 사용할 수 있는 메서드와 그럴 수 없는 메서드가 있기 때문입니다. 그리고 이러한 메서드는 여러분이 만든 API의 작동 원리를 다른 사람들에게 설명하기 위한 기본적인 토대의 역할도 합니다. 아무튼 이런 HTTP는 우리가 모두가 사용하고 있는 수많은 인터넷 인프라를 뒷받침하고 있는 중요하면서도 기본적인 규약(프로토콜)입니다. 따라서 적절한 용도에 적절한 메서드를 사용하는 것이 중요합니다.

 

 

기존의 메서드에 무슨 문제가 있을까?

사실 기존의 메서드도 상당히 괜찮기는 하지만, 몇 가지 아쉬운 부분이 있습니다. 예를 들어서 복잡한 데이터를 검색한다고 해 보겠습니다. 그러려면 당연히 서버 쪽으로 보내야 하는 데이터도 많은 것입니다. 하지만 서버의 상태는 변경하고 싶지 않다면 어떻게 해야 할까요?

 

기본의 메서드로 할 수 있는 방법은 두 가지가 있습니다.

  • GET을 사용해서, 필요한 모든 매개변수(parameter)들을 URL이나 헤더 등에 어떻게 해서든 전부 집어넣는 것입니다.
  • POST를 사용해서, 안전하지 않고 캐시를 사용할 수도 없는 요청을 보내는 것입니다.

 

그런데 둘 다 그다지 좋은 방법은 아닙니다.

 

왜냐하면 URL의 길이에는 제한이 있으며, 헤더의 크기에 대해서 HTTP 표준에서는 별도의 제한을 두고 있지는 않지만 상용으로 출시된 웹 서버에서는 제한을 두고 있는데, 그 값이 전부 제각각입니다. 따라서 URL에서 특수 문자나 줄 바뀜 등이 발생할 경우에는 별도로 부호화를 해야 하기 때문에, URL 자체만 읽었을 때는 도무지 무슨 의미인지를 알 수가 없게 됩니다. 그렇다고 해서 그렇게 복잡한 URL을 해석하는 걸 도와주는 별도의 정보를 넣어 놓을 수도 없으며, 이러한 작업을 좀 더 쉽게 도와줄 수 있는 도구도 사실상 찾아볼 수 없습니다. 그렇기 때문에 필요한 쿼리(query, 질의)를 전부 모아서 문자열을 만드는 작업은 여러분 혼자서 직접 해야 합니다. 굳이 이렇게까지 해야 할 필요가 있을까요?

 

그리고 인터넷의 구조에서 캐시는 아주 중요한 기능이지만, POST를 이용하면 그 모든 게 완전히 무효화됩니다. 그리고 POST 메서드를 이용해서 이러한 요청을 처리하면 근본적인 문제가 있습니다. 왜냐하면 단순히 검색 요청을 했을 뿐이기 때문에 서버에는 어떠한 상태도 변경하지 않아야 하고, 어떠한 부작용도 일으키지 않아야 하겠지만, 실제로는 마치 이 요청이 무슨 문제라도 일으킬 가능성이 있는 것처럼 관련된 모든 캐시를 삭제해 버리기 때문입니다.

 

그리고 복잡한 쿼리를 전송하려고 하는 리소스의 종류와, 데이터를 보내려고 하는 리소스의 종류는 동일한 것입니다. 그렇다면 과연 POST 메서드를 통해서 새로운 고객에 대한 항목을 생성하라는 명령을 보내면서, 동시에 고객에 대한 정보를 요청하는 쿼리를 전송할 수 있을까요? 물론 POST 메서드로도 가능하긴 하지만, 동일한 리소스에 대해서 여러 번에 걸쳐서 요청을 해야 합니다. 따라서 작업 시간이 오래 걸리고 복잡한 소프트웨어가 될 가능성이 높습니다. 다행히도, HTTP는 지금도 계속해서 발전하고 있는 표준이기 때문에, 이런 문제들을 충분히 개선할 수 있습니다.

 

 

HTTP SEARCH 소개

이러한 문제를 해결하기 위해서 새롭게 제안된 메서드가 바로 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가 가진 장점은 다음과 같습니다.

  • 요청 바디는 특별히 부호화를 해야 한다거나, 길이의 제한도 없기 때문에 가독성이 좋으며 관리하기도 쉽다.
  • 데이터에 대한 쿼리(질의)만을 전송하는 것이기 때문에, 의미가 명확하다.
  • 동일한 URL을 기반으로 GET, SEARCH, POST라는 개별 메서드를 자유롭게 이용할 수 있다.

 

 

사용 예시

SEARCH를 이용하면 그래프QL(GraphQL)에서부터 일반 SQL은 물론이고 오픈데이터 프로토콜(OData)에 이르기까지 다양한 환경에서도 복잡한 쿼리를 지원할 수 있습니다. 물론 클라이언트가 사용하는 쿼리 언어가 무엇인지를 서버가 알아야 하지만, 그런 문제는 요청 메시지의 헤더에서 Content-Type으로 명시해 놓으면 아주 쉽게 해결할 수 있습니다.

 

SEARCH는 특히 GraphQL을 사용할 때 더욱 흥미롭습니다. GraphQL은 GET 메서드와 POST 메서드를 모두 지원하고 있지만 그로 인해서 겪는 곤란한 점들이 있기 때문에, 위에서 살펴본 문제점들에 딱 들어맞는 사례라고 할 수 있습니다. GraphQL을 이용한 읽기 전용 요청에서 SEARCH 메서드를 이용한다면 UX를 상당히 개선할 수 있으며, 향후의 캐시 처리와 같은 HTTP의 자체적인 기능과 GraphQL을 더욱 잘 연동되게 해 줄 것입니다.

 

이러한 쿼리 언어는 가장 대표적인 사례이긴 하지만, SEARCH는 그 외에도 훨씬 더 많은 부분에서 사용할 수 있습니다. 왜냐하면 서버로부터 데이터를 요청하기 위해서 메시지를 보내기 위한 기능을 전부 지원하면서도 부작용은 없기 때문입니다.

 

 

Accept-Search

여기에 더해서 SEARCH 메서드에는 Accept-Search라는 헤더가 있습니다. 이 헤더는 응답 메시지에서 사용되는데, 그 모습은 아래와 같습니다.

이 헤더는 클라이언트가 보낸 SEARCH 요청을 서버가 수락(accept)했음을 알리는 것이며, 앞으로 서버가 받을 수 있는 쿼리의 형식들을 알려줍니다. 이는 기존의 Accept-Patch 헤더와 비슷합니다.

 

서버는 이 헤더를 어떠한 응답 메시지에서도 포함시킬 수 있지만, 특히 옵션(OPTIONS) 메서드에 대한 응답에서 유용하게 쓰일 수 있습니다. 왜냐하면 OPTIONS는 서버에 있는 리소스가 어떤 특성을 지원하는지를 클라이언트 쪽에서 물어보는 메서드이기 때문입니다.

 

 

주의사항

개인적으로 SEARCH는 상당한 진전이라고 생각하지만, 현재로서는 다소 오해를 불러일으킬 수도 있고 개선의 여지가 있는 부분이 있어서 주의가 필요합니다.

 

 

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'을 각색하여 작성되었습니다.

댓글 0

요즘IT의 번역글들

이 프로필을 만든 저만 해도 영어가 서툴러 영어로 된 기사는 읽는 게 더딥니다. 그래서 준비했습니다. 읽어볼만한 해외 소식들을 번역해 전합니다. We are the world.

북극성 지표(North Star Metric) 선택하기

비즈니스

피그마는 여러분을 나쁜 디자이너로 만들고 있습니다

디자인

인터랙션 디자인 vs 시각 디자인

디자인

좋은 디자인 포트폴리오를 만드는 팁

디자인

나에게 맞는 웹 기술 스택을 고르는 방법

개발

윈도우11은 실패작이다

프로덕트

“파이썬은 느리다”에 대한 반론

개발

파이썬 초보자가 저지르는 10가지 실수

개발

우리가 주목할 UI/UX 디자인 트렌드

디자인

2022년 프론트엔드 개발 동향

개발

코드 리뷰 문화

개발

데이터 분석가는 무슨 일을 할까요?

개발

최고의 오픈 소스 개발 도구 Top 8

개발

데이터 분석이란 무엇일까?

개발

Flutter로 UI를 구현하는 방법

개발

자바 언어의 장단점과 2022년 트렌드

개발

데브옵스(DevOps) vs 데브섹옵스(DevSecOps)

개발

엑셀을 사용한 아름다운 데이터 시각화

디자인

여러분을 더 나은 플러터 개발자로 만들어줄 7가지 프로젝트

개발

모든 디자이너가 숙지해야 할 피그마 팁과 노하우

디자인

디자인 원칙과 디자인 가치, 그리고 디자이너

디자인

디자인, 산출물 그 이상을 넘어

디자인

이 회사는 디자인에 투자하고 있는 회사일까요?

디자인

애자일은 정말 디자인을 배제하나요?

디자인

평판 관리가 프리랜서 경력에 미치는 영향

프리랜싱

리액트 네이티브 개발자들이 겪는 가장 빈번한 5가지 문제와 해결책

개발

“솔직히 우리가 하는 것은 스크럼이 아닙니다!”

기획

데이터 시각화가 인류를 위기에서 구한 세 가지 역사적 사건

디자인

NFT의 장밋빛 미래는 사실일까?

기획

피그마 토큰으로 디자인 시스템 만들기

디자인

디자이너+개발자 = 슈퍼팀 만들기

기획

1인 개발자로서 테크 스타트업을 운영하며

기획

웹 디자이너가 PX대신 REM을 사용해야 하는 이유

디자인

100개의 스타트업을 멘토링하며 깨달은 성공의 비밀

기획

중화권 앱 UI가 영미권 앱 UI와 다른 점 알아보기

프로덕트

내가 테크 리더로 일하면서 얻은 8가지 교훈

기획

모두가 즐길 수 있는 디자인 검토 회의 만들기

디자인

프로덕트 매니저에서 프로덕트 마스터로

기획

10배 이상 뛰어난 개발자가 되는 법

개발

제품 디자인 관점에서 바라보는 NFT 아바타 열풍

디자인

에어비앤비: 대규모 iOS 앱 개발 생산성을 위해 바꾼 것들

개발

스포티파이: 맞춤형 플레이리스트 개발 비하인드 스토리

개발

프리랜서가 일하게 될 15가지 유형의 프로젝트

프리랜싱

슬랙: 제품 원칙을 통해 다시 태어난 알림 기능

프로덕트

페이팔: 실시간 그래프 데이터베이스 분석을 통해 사기를 방지하는 방법

개발

트위터: 수십억 개의 이벤트를 실시간 처리하기

개발

슬랙: 4가지 애자일 가치와 방법

기획

스퀘어: 모바일 우선을 넘어 웹에서 누리는 모바일앱 경험

디자인

스포티파이: 카피를 언어로 만드는 UX 라이팅

기획

마이크로소프트: 디자인의 미래를 위한 4가지 원칙

디자인

메타: AR/VR 경험까지 고려한 디자인 청사진

프로덕트

슬랙: 훌륭한 마케팅 카피를 위한 5가지 원칙

기획

2022년 UX/UI 디자인 트렌드

디자인

구글: 가변 폰트의 놀라운 활용법

디자인

에어비앤비: 위기 상황에서의 디자인 원칙 5가지

디자인

어떻게 두 명의 인턴이 수백만 개의 코드들을 보호할 수 있었나

개발

Lattice로 마이크로 프론트엔드를 구축하는 법

개발

Cool Cats NFT를 구축하면서 배운 것

개발

웹 컴포넌트가 프론트엔드 프레임워크를 대신할까?

개발

당신이 NFT에 대해 알아야 할 모든 것

개발

우리에겐 이상하지만 개발자들에겐 일상인 일들

개발

Next.js 12에서 주목해야 할 5가지 변화

개발

스벨트 vs 리액트, 누가 더 뛰어날까?

개발

개발자를 위한 iOS 15의 새로운 기능

개발

내가 오픈소스를 싫어하는 이유

개발

프로덕트 매니지먼트 고객 여정 5단계

기획

클럽하우스의 인기는 모두 거품이었다?

프로덕트

데이터 기반 의사결정의 장점

기획

시각 디자인의 폐쇄성 법칙이란?

디자인

사용자 경험(UX) vs 서비스 디자인

기획

프로덕트 매니저는 하루 종일 무슨 일을 할까?

기획

제품 주도 성장은 어떻게 이루어지는가?

기획

UX를 망치지 않는 설득력 있는 배너 디자인

디자인

팝업(Pop-up)으로 불리는 것들에 대하여

디자인

드롭다운(Drop-down)으로 불리는 것들에 대하여

디자인

당신의 생각을 표현하는 새로운 이모지

디자인

가장 똑똑한 소프트웨어 엔지니어에게 배운 10가지 교훈

개발

성공적인 UX 프로젝트를 위한 가장 중요한 질문

디자인

2021년, UI 디자이너가 모바일 앱에서 흔히 저지르는 실수

디자인

IT 매니저가 되는 방법과 성공하기 위한 요소

기획

슬랙(Slack) 같은 앱을 만들려면 비용이 얼마나 들까?

개발

아웃소싱이 이토록 인기를 얻게 된 이유는?

아웃소싱

마케터가 UX 관련 역량을 키워야 하는 이유

기획

미니멀리즘 디자인의 핵심적인 요소들

디자인

새로운 소프트웨어 개발사가 필요하다는 7가지 신호

아웃소싱

2021년을 이끌어가는 프론트엔드 개발 트렌드 5가지

개발

PM을 성장시키는 학습 프레임워크

기획

UI 카피라이팅, 어떻게 써야 하나요?

기획

트렌드 예측: 경쟁에서 앞서는 방법

기획

제품 사고(product thinking)의 힘

기획

인하우스 vs 아웃소싱, 소프트웨어 개발 어떻게 하나요?

개발

그림을 못 그리는 사람도 쉽게 와이어프레임 그리는 방법

기획

스타트업 기업들에게 아웃소싱이 중요한 이유

아웃소싱

제품과 기능, 성공적으로 종료하는 방법 (下)

기획

제품과 기능, 성공적으로 종료하는 방법 (中)

기획

제품과 기능, 성공적으로 종료하는 방법 (上)

기획

UX 디자이너에게 반드시 필요한 12가지 스킬

디자인

패스워드 없는 세상이 오고 있다

개발

디자이너를 쉽게 잃는 방법 10가지

디자인

프론트엔드 코딩 작업에 영감을 줄 8가지 아이디어

개발

구글이 아웃소싱을 하는 이유: 아웃소싱 성공사례 5가지

아웃소싱

일 잘하는 PM이 되기 위한 로드맵 도구 5가지

기획

이제는 말할 수 있다! 아웃소싱에 대한 오해 11가지

아웃소싱

디자인 트렌드, 모던 미니멀 스타일의 UI 가이드

디자인

MVP 개발을 아웃소싱으로 해도 될까요?

개발

온보딩 효과를 높이는 '좋은' 귀차니즘 3가지

기획

게임처럼 즐겨라, 게임화 기법 TOP3

기획

시니어 소프트웨어 엔지니어는 어떻게 일할까?

개발

프로덕트 매니저가 글을 잘 써야 하는 이유

기획

2030년엔 사라질 수도 있는 프로그래밍 언어 5가지

개발

고객들이 언제나 옳은 것은 아니다

기획

유저 스토리는 무엇인가?

기획

고객 성공을 위한 14계명

기획

8px 그리드 시대가 끝나고, 4px 그리드의 시대가 열릴까?

디자인

모바일 앱은 더 이상 스타트업에게 좋은 아이디어가 아니다

기획

과연 구글의 UX 강좌는 도움이 될까요?

디자인

프로덕트 매니저 여러분, ‘소비자의 요구사항 수집’을 그만두십시오

기획

고객 여정과 경험 지도의 차이점

기획

내가 AI 업계를 떠난 이유 5가지

기획

모달윈도우(팝업)를 디자인할 때 생각할 9가지 원칙

디자인

대기업 vs 중소기업, B2B SaaS 스타트업을 위한 시장은?

기획

내가 개발 인터뷰에서 면접자에게 감동한 이유

개발

세상의 모든 프로덕트 디자이너를 위한 5가지 심리학 원칙

디자인

2021년 테스트 자동화 트렌드 리포트 (下)

개발

2021년 테스트 자동화 트렌드 리포트 (上)

개발

아마존과 스포티파이는 어떻게 사용자를 유지하고 측정할까?

기획

UX 디자이너라면 필수적으로 알아야 할 5가지 법칙

디자인

앵귤러 vs 리액트, 2021년의 승자는?

개발

2021년, SaaS 스타트업 시작을 위한 놀라운 아이디어 10가지

기획

디지털 제품 관리에서 B2B와 B2C 사이의 차이점은?

기획

빠르게 실행할 수 있는 ‘제품 요구사항 문서(PRD)’ 만들기

기획

더 나은 제품을 위한 프로덕트 메트릭스 가이드

기획

노 코드(No Code) 트렌드로 프로그래머들은 일자리를 빼앗길까?

개발

넷플릭스의 플랫폼: 코스모스(Cosmos)에 대하여

프로덕트

비즈니스와 애자일 조직은 어떻게 친해질 수 있을까요?

기획

효과적인 제품 전략 세우기: 다수의 전략적 트랙(MuST) 활용

기획

1년 만에 이메일 마케팅 효과를 극대화했던 방법

기획

솔루션 아키텍트를 위한 팁: 아키텍처 다이어그램의 5가지 유형

개발

새로운 맥 OS ‘빅서’에 대한 UX 디자이너의 생각

디자인

디자인 트렌드, 뉴모피즘의 정석

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 3편

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 2편

디자인

2021년 모바일 UX 트렌드 10가지

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 1편

디자인

앱 설정 기능의 UX를 개선하는 효과적인 방법

디자인

다크모드 UI 디자인의 원칙

디자인

온라인 고객 경험을 개선하기 위한 5가지 방법

기획

신생 스타트업에서 일하는 프로덕트 매니저를 위한 현실적인 조언

기획

웹 개발자와 소프트웨어 개발자의 차이는 무엇인가요?

개발

랜딩 페이지 디자인을 개선하는 13가지 꿀팁

디자인

오프라인 비즈니스가 온라인에서 존재감을 가져야 하는 이유 5가지

기획

상향식 가격 책정 및 패키징 정책: 사용자 여정을 가이드로 활용하기

기획

B2B 제품의 UX, 그것은 숨겨진 영역인가요?

기획

상단 내비게이션 vs 사이드 내비게이션, 어느 것이 더 나을까?

디자인

자동완성 검색 기능 UX 설계를 위한 8가지 팁

디자인

프로덕트 매니저는 전문적인 IT 기술을 갖춰야 하나요?

기획

실리콘밸리 51개 기업들이 말하는 프로덕트 매니저의 역할 9가지

기획

아웃소싱에 대한 모든 것

아웃소싱

앱 디자인 가이드, 사람들이 즐겁게 사용할 수 있는 앱을 만드는 법

디자인

처음부터 완제품이 아니라 ‘MVP’를 만들어야 한다

기획

플러터 vs 리액트 네이티브 vs 네이티브, 성능이 더 우수한 것은?

개발

스타트업 프로덕트 매니저로 성장하는 법, 30-60-90일 플랜

기획

당신의 두뇌는 진보하고 있다: 성취감을 위한 3가지 전략

기획

디자이너들을 편하게 해주는 HTML/CSS 마법 10가지

디자인

코딩의 미래는 ‘노 코드(No Code)’이다

개발

내가 엔지니어링 매니저로 일하면서 저지른 실수들

개발

내가 롬 리서치(Roam Research)를 좋아하는 이유와 실제 사용법 (下)

기획

내가 롬 리서치(Roam Research)를 좋아하는 이유와 실제 사용법 (上)

기획

프로그레시브 웹 앱(PWA)이란 무엇이며, 왜 필요한가?

개발

PWA vs 네이티브 앱, 어떤 것을 선택해야 할까?

개발

UI 디자인에 여백을 활용하는 8가지 팁

디자인

마이크로소프트와 링크드인의 새로운 시도, 프리랜서 마켓에 도전장을 던지다

기획

토마스넷은 왜 가입자 수를 폭발적으로 늘려준 테스트 결과를 거부했을까?

기획

잘 팔리는 기업용 소프트웨어 디자인하기

디자인

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 하편

개발

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 중편

개발

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 상편

개발

업워크(Upwork)가 조사한 요즘 가장 인기 좋은 개발 기술 15가지

개발

일자리 산업이 휴먼 클라우드(human cloud)에 적응하는 방법

기획

팬데믹 이후 세계에서의 디지털 가속화는 어떤 모습일까?

기획

같은 분야를 다룬 글들을 권해드려요.

요즘 인기있는 이야기들을 권해드려요.

일주일에 한 번!
전문가들의 IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.

일주일에 한 번! 전문가들의 요즘IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.