[elasticSearch] ElasticSearch 6.0 Contents-Type 설정 이슈

elasticSearch

1. 왜.

• elasticSearch의 값이 예전과 같이 들어가지 않는다.
• 예전이라 하면 아래와 같은 콜이다.

curl -XPOST 'http://localhost:9200/classes/class/1/' 
 -d '{"title":"Algorithm", "professor":"John”}'

• err! 젠장!

{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}curl: (6) Could not resolve host: professor

2. 그래서 무엇인가.

• elasticSearch를 테스트하면 설치를 반복하다 6.0버전이 나와 6.0을 받아버린게 차이점을 불러 왔다.
• 6.0 에서는 왜 위와 같은 콜이 들어가지 않을까?

3. 써보자.

결론은, 6.0 버전부터 Rest Request에 ContentType checking이 엄격하게 들어가게 변화되었다.

• 이전에는 (6.0 이하) 콘텐츠 타입이 옵셔널이어여서 누락되거나 인식되지 않게되었다. 그 몫은 고스란히 서버에서 처리되어야하는 경우로 남게된것이다.

• 6.0부터는 그런일이 일절 발생하지 않도록 콜자체에 content-type을 명확하게 입력해야 하게 되었다.

• 물론 http.content_type.required configuration을 통해 위의 사항을 선택할 수 있다. 그러나 기본값은 TRUE 이다

curl -XPOST http://localhost:9200/test/hi -H 'Content-Type: application/json' -d '{"title":"bca","professor":"john”}'

• 결론적으로 위와같이 Content-type을 붙여주면 아주 잘 ~ 들어간다. 다소 불편하다 생각되면 기본값을 바꿔주면 된다.

4.마치며

• elasticsearch를 깊게 써보지 않아 contentType에 대한 어떠한 이슈가 가장 클지는 가늠할 수 없었다.
• 다만, 관련 문서의 문구처럼, 추측하는 것보단 안정적이고 예측가능한 결과를 제공하는것에 더욱 큰 비중을 둔것은 매우 큰 의미가 있다고 생각한다.
• 개발 비기너로서, 코드의,컨포넌트의,무언가가 됬든 명확하고, 안전한 접근은 100번 강조하더라도 부족하지 않을 것이다.

Ref.

• elasticSerach,Strict Content-type