10P by xguru 2021-04-16 | favorite | 댓글 9개

- IETF에 새 Draft로 추가된 SEARCH 메소드 소개
- 복잡한 데이터를 가져오기 위해선 기존 GET/POST 만으로는 비효율적

SEARCH /customers HTTP/1.1
Host: example.com
Content-Type: application/sql

SELECT username, email
WHERE DATEDIFF(DAY, GETDATE(), signup_date) > 7

- 실제로 SQL문장이 표준으로 사용되는 건 아니고, 리퀘스트 바디에 검색을 위한 이런 컨텐츠가 가능하다는 것
- 이를 통해서 한개의 URL에 대해서 GET,POST,SEARCH 가 모두 가능해짐
- Accept-Search 헤더를 통해서, 검색에 사용하는 포맷들을 지정 가능 :
ㅤ→ Accept-Search: application/sql, application/graphql
- WebDAV 에 있었던 SEARCH 메소드 표준에 기반 (rfc5323)

OData가 거의 비슷하게 이런 방식으로 쿼리하는 규약입니다. 하지만 application/sql과 application/graphql을 같은 endpoint에서 사용할 수도 있다니.. 좀 상상이 안가는군요

용도자체는 SQL을 직접 때리는건 문제가 있고 elasticsearch처럼 semantic하게는 get이지만 HTTP Body를 넣어서 조회하고 싶은 경우에 쓰게 되지 않을까 싶습니다.

글 초입 부분에 "it was recently adopted as an IETF draft standard"라고 하는데 여기서 말하는 recently가 2015년이 맞나요? 제가 본 드래프트는 https://tools.ietf.org/html/draft-snell-search-method-00 이건데, 혹시 더 최신 변경사항이 있나 해서요.

https://datatracker.ietf.org/doc/… 입니다.
최근 2021-03-31 에 업로드 되었네요.

body에 정보를 실어 보내려면 PUT이나 POST를 써야할텐데.
얘네들은 cache를 사용할 수 없으니
SEARCH 라는갈 쓸 수도 있겠네요.
아차피 accept한 경우에만 보내면 되니.

get,post 의 불편함을 개선하고자 하는 방향에서 graphql 이 생각나네요

쿼리를 리퀘스트 바디로 넘기기 시작하다 보면 언젠가 (별 생각 없이 만든 사이트라면) SQL Injection 같은 문제가 생길것 같은 느낌이 오네요..

body가 있는 GET 정도로 이해하면 될 것 같네요. 어차피 body를 validation은 해줘야 할꺼고...