php 안에서 외부 서버로 api 호출을 해야했습니다.
curl은 너무 코드가 길어지고 예쁘질 않아서 이번엔 다른 방법으로
해보려고 했죠.
http_* 계열 함수가 심플해서 api 호출에는 좋아보이더군요.
근데 이게 웬걸?? put은 http_put_file 밖에 없습니다.
post는 http_post_data, http_post_file 이렇게 두종류가 있는데 말이죠.
이 이러면 put으론 api 못날리는데.. 이거 뭔가 좀 이상하네..
php 내장 함수가 상태가 왜 이렇지?
좀 이상해서 찾아봤더만 이게 원래 HTTP메소드에서 PUT이라는게
제 생각하고 좀 틀린 의미더군요.
rest api에서 보통 post는 new, put은 update의 의미로 쓰고 있는데
http메소드 원래의 의미에서 put은 파일같은걸 통채로 보낸다는 의미더군요.
그리고 update의 용도는 HTTP메소드중에 patch가 담당하고 있는거 같았습니다.
아니.. rest api들은 맨 처음에 대체 왜 put을 update라는 의미로 사용한거죠?
patch라는 합당한 메소드가 따로 있는데 대체 왜....
HTTP 메소드 원래 의미를 알고 나니까 PUT을 update의 의미로 해서 api를
설계하는데 굉장히 거부감이 느껴지는군요..
하긴 REST API라는걸 첨 알게 되었을때부터 좀 이상하긴 했어요..
post나 put이나 단어 뜻에서 별 차이가 안나는데
왜 하나는 new고 하나는 update일까... HTTP 메소드가 저거 4개밖에
없어서 그냥 끼워맞춘건가? 했었는데 말이죠.
왜 최초의 REST API 설계자는 patch 대신 put을 선택한걸까..
그리고 어쩌다가 그게 거의 표준이 되어버린걸까... 궁금하기 짝이 없습니다.
개발자들은 뭔가를 수정할 때 "패치한다"고 하잖아요.
PUT = 통째로 덮어씌운다.
PATCH = 일부만 패치한다.
그런데 패치를 제대로 하려면 git처럼 패치 문법에 맞게 작성해서 전송해야겠죠? 그거 귀찮잖아요? 요즘 많이 쓰는 JSON은 일반적인 패치 문법에 맞지도 않고요. 그러니까 그냥 PUT!!! 통째로 덮어씌워버려!!! ㅋㅋㅋ
물론 현실에서는 API 설계하는 사람마다 제각각이고, 웹에서는 거의 모든 작업을 POST로 때우고 있으니 원래 의도는 안드로메다로...
그런데 생각해 보면 현대의 인터넷에서 원래 의도대로 PUT이나 PATCH를 사용하기는 매우 위험합니다. PUT은 마치 FTP처럼 사용자가 지정한 URL에 사용자가 보낸 데이터를 그대로 올려놓는 것이고, PATCH도 전체가 아닌 일부를 수정한다는 차이뿐 기본적인 개념은 비슷하니... 처음 REST를 설계한 분들은 접속 권한이 있는 사람이라면 누구나 신뢰할 수 있다고 생각했나 본데, 이제는 보안 때문에라도 이 메소드들을 원래 의도대로 사용할 수가 없어요. 전송한 데이터를 가공 없이 그대로 올려놓는다고 보장할 필요가 없고, 처리 방법은 물론 URL까지도 서버에서 결정권을 갖는 POST가 널리 쓰이는 것도 이상한 일이 아닙니다.