|
:: 게시판
:: 이전 게시판
|
- PGR21 관련된 질문 및 건의는 [건의 게시판]을 이용바랍니다.
- (2013년 3월 이전) 오래된 질문글은 [이전 질문 게시판]에 있습니다. 통합 규정을 준수해 주십시오. (2015.12.25.)
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
17/10/14 12:38
Http는 파일을 전송하는 방식의 한가지 프로토콜이고 Rest는 스케일할 수 있게 APi를 설계하는 방법 중 하나라고 표현하면 되려나요.?
밑에 분이 자세하게 더 설명해 주시겠지만 www같은 인터넷은 REST API기반으로 만들어져있고 파일 전송 프로토콜로 http를 채택한 경우라고 보시면 됩니다. Http가 아닌 ftp같은 방법을 선책할 수도 있었지만 안한 것 처럼요. Http 메소드는 겟 포스트로 전송 관련 verb를 사용하지만 RESTful하게 만들기 위해서, 즉 스케일하기 위해서 또는 더 편하게 만들기 위해서 put, delete등과 같은 REST 프로토콜의 verb를 사용하는걸로 알고 있습니다. 즉 Http와 rest는 다른 것이지만 인터넷은 두가지를 합한 것이라고 보시면 됩니다
17/10/14 12:58
(수정됨) GET/POST가 기술적으로 분화된 것이 아니고, HTTP 1.1을 정의할 때 이미 그런 의미적인 부분들이 들어있었습니다 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)
REST를 설계할 때 (기존에 잘 쓰이지 않던) HTTP의 개념을 가지고 일종의 표준화를 시도한 것입니다. 물론 강제되는 사항은 아니지만, 일종의 약속으로 생각하시면 됩니다. 이런 약속을 했을때 장점 중 하나로, 프로그래머가 새로운 API를 쓰려고 할 때, 동작을 대략이라도 예측할 수 있게 됩니다. 브라우저의 동작도 달라지구요. (가령 캐시라던가, 새로고침을 해도 되는가 안되는가 같은 것들). 예를 몇 가지 들어보면, GET은 리소스를 읽는 동작으로 약속되어 있고, POST는 리소스를 만드는 동작으로 약속되어 있습니다. 따라서 사용자가 새로고침 버튼을 누를 떄, GET인 경우에는 걱정 없이 바로 보여주는 반면, POST인 경우에는 폼이 재전송될 수 있다는 경고를 띄워주죠. 리소스가 두 번 생성될 수 있으니까요. 또한 POST는 새 리소스를 만드는 동작, PUT이나 PATCH는 기존 리소스를 업데이트하는 동작으로 약속되어 있습니다. 이런 약속이 없다면 새 API를 쓸 때마다 이게 업데이트인지 생성인지 일일이 찾아보면서 만들어야 하고 심지어 API마다 다 다를 수도 있고요. 또 검색엔진들이 페이지를 크롤링할떄, GET 메서드는 리소스를 바꾸지 않아야 하기 때문에, 안전하게 글을 긁을 수 있습니다. 만약 게시판에 글을 쓰거나 삭제하는 메소드가 GET으로 구현되어 있다면? 시도 때도 없이 새 글이 생기거나 사라지겠죠.
17/10/14 13:34
Rest는 주소를 통해서 접근하는 대상이 웹 페이지라기 보다는 하나의 리소스입니다. (리소스에 웹페이지가 포함될 수는 있습니다.) 흔히 Rest를 단순하게 이해하려는 사람들이 Rest는 HTTP + JSON이다 라고 단정짓는 경우가 있는데, 실제로 Rest가 저 리소스를 JSON으로 전달하는 경우가 많아서 그렇습니다. HTML로 웹 페이지를 전달해도 Rest 방식일 수 있습니다.
단순화 시켜서 pgr21.com/member 는 pgr21의 회원정보(리소스)를 표현하는 주소로 볼 수 있습니다. 저 주소를 GET으로 요청하면 회원정보를 보내달라는 요청이 될 수 있습니다. pgr21.com/member/abc123 의 경우 pgr21의 회원정보 중 abc123이라는 ID를 가진 사람을 나타내는 주소가 될 수 있습니다. 이 주소를 GET으로 요청할 경우 abc123의 정보를 보내달라, 같은 주소를 POST로 요청할 경우 내가 보낸 내용으로 저 사람을 추가해달라는 요청이 될 수 있습니다. 보통 예전에 웹 서비스는 서비스 제공, 그러니까 무엇을 할 것인가에 집중했기 때문에 pgr21.com/newMember.do?id=abc123 이런 식으로 주소 자체가 어떤 구체적인 요청을 가지고 있었다면, REST 방식은 무엇을 대상으로 하느냐가 주소로 기록되기 때문에 그 대상에게 무엇을 할 것이냐는 보통 HTTP Mehod (GET, POST, UPDATE, DELETE)로 표현하는 약속이 정해진 것입니다. 물론 실제로 리소스에 대한 모든 동작이 저 method 들로만 표현될 수는 없기 때문에 Restful한 웹 서비스라는 것이 이렇게 단순하게 표현되지는 않지만 어쨌든 배경은 그렇습니다.
17/10/14 15:41
HTTP/1.1 "규약"에서 그 Method로 HEAD, GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE (나중에 PATCH 추가) 등을 이러이러하게 쓰기로 사전에 "약속"을 한 것입니다.
그리고 REST는 그 HTTP 규약에 의해 약속된 바를 잘 지켜서 쓰자는 "방법론" 혹은 "관행"이죠. 이미 HTTP 규약에 따라 적절한 메소드가 다 있는데, 뭐하러 GET /delete_member.jsp?id=1234 같은 식으로 쓰냐는 거죠. 우리 친구들이 다들 GET, POST만 쓰고 있는데, 우린 이미 DELETE도 갖고 있고 모르겠으면 OPTIONS로 Allow: 받아오면 되고, 여튼 DELETE /member.jsp?=1234 같은 더욱 간명하고 딱 보이는 길이 있는데, 왜 다들 GET, POST만 쓰냐는 거죠.
17/10/15 14:27
(수정됨) restful하지 않았던 시대의 개발을 생각해보면 restful을 왜 쓰는지, 써야하는지를 이해하실 텐데요,
유저가 하나의 캐릭터를 가지고 있을때 이것을 업데이트한다고 하면 아래와 같은 URL을 만들 수 있습니다. /user_character/update /get_user_character/update_character(POST로 user, character 정보를 get할 수 있는 정보가 들어가고 업데이트할 정보도 포함) 단순히 말씀드리면 이전까지 URL을 설정하는 것은 회사마다, 사람마다, 기관마다 다른 방식이고 이것에 대한 문서화가 없으면 새롭게 작업을 진행하거나 url을 예측하기가 무척 어렵습니다. 규율이 빡빡하지 않으면 같은 회사여도 개발 팀단위로, 혹은 작업자 단위로 url routing 을 조금씩 다르게 하고 있을 겁니다. restful은 이러한 것에 일종의 공통룰을 도입했다고 보시면 될 듯합니다(http 기본을 충실히 따르는). 유저가 하나의 캐릭터를 가지고 있을때 이것을 업데이트한다. 거의 대부분 아래와 같은 형태의 URL 과 파라미터가 만들어 질 것입니다. /user/character (PUT) 과거에는 하나의 서비스만으로도 모든 것을 처리할 수 있었다면 현재는 그렇지 않습니다. 대부분의 경우 하나의 웹 서비스는 다른 하나 이상의 웹 서비스와 상호 연결성을 지닙니다. 그러니 이 부분에서도 문서 없이 url을 대강이라도 눈치 챌 수 있거나 혹은 직관적인 것이 개발에 큰 도움이 됩니다. 특정 기술이 왜 유행하는지에 대한 가장 근본적인 이유는, 그 기술을 쓰지 않았을 때는 어떠했는가를 이해하시면 될듯합니다.
|
||||||||||