세미나에서 나온 REST에 대해서 질문이 있습니다.

[Outsider ..]

Spring in REST에서 궁금한 점이 있어서 메일을 씁니다.

박찬욱님이 의도하신 바가 경험하신 프로젝트의 경우를 예시로 하시다 보니 전달(혹은 제가 이해를 잘못)하는데 약간 혼동의 여지가 있었는지는 모르겠지만 제가 아는 범위에서는(REST에 대해 자세히 알지는 못합니다.) REST에 대한 설명에 좀 잘못된 점이 있지 않을가 하는 생각을 계속 했습니다.

세세한 부분들은 모든것을 다 설명할수 없어 생략하다보니 그렇다고 하더라도 제가 동의 할 수 없는 부분은 아래 부분인데요.

--------------------------------------------------

REST는 뷰가 없이 json과 XML의 형태로 내려주는 것이다.

그래서 프론트앤드에서 모두 Ajax로 끌어와야 하기 때문에 어렵다.

그런데 프론트앤드는 이에 대한 준비가 제대로 되어 있지 않고 리치클라이언트가 이런 패턴에 익숙해서 더 낫다.

--------------------------------------------------

제가 잘못 이해했는지 모르겠고 간결히 핵심을 정리하다보니 비약이 있는지는 모르겠습니다만 제가 이해하기에는 위 흐름이 설명의 맥락이었다고 생각합니다.

먼저 REST의 ROA(리소스 기반 아키텍쳐)에서 리소스를 무엇으로 정의할 것인가는 저도 경험상 꽤 어려운 부분이고 그에 따른 도메인에 대한 고민도 상당히 공감하는 부분입니다만 

REST는 기존의 액션을 file명으로 하던 것을 리소스에 기반을 두어 같은 리소스는 같은 URL을 가지고 액션은 HTTP의 method를 이용해서 구분하는 것이라고 이해하고 있는데 그 결과가 HTML인지 JSON인지 XML인지는 REST와는 전혀 상관없는 부분이라고 알고 있습니다.

제가 스프링의 REST는 사용해 본적이 없어서 어떻게 정의되어 있는지는 모르겠지만 스프링의 위상을 생각했을때 json이나 XML만 사용하도록 강제했을것 같지는 않다고 생각합니다.(text/html로 요청하면 컨텐츠 네고시에이션 리졸버인가에서 text/html로 리턴해 주는 것이 맞는것 아닌가요?) 그뒤에 이어지는 ajax로 데이터를 끌어와야 해서 어렵다던가 리치클라이언트가 더 낫다는 얘기는(개인적으로는 프론트앤드가 준비가 되어 있지 않다는데 동감하지 못하고 있지만 이런건 각자 다를 수 있는거니까요.) REST에 대한 전제가 잘못되어서 나온 얘기로 생각됩니다. 

저로써는 REST의 정의에 대해서 오해의 여지가 있다고 생각해서 세션내내 상당히 집중하지 못하고 들었었는데요 다른 분들은 어떻게 생각하시는지 궁금합니다. 제가 잘못 알고 있는것인가요?

--
/************************************************

Outsider

Front-end & Server-side Developer

Blog : http://blog.outsider.ne.kr

Twitter : @outsider

G-Talk : outsideris@gmail.com

*************************************************/

[Sungchul Park]

세미나의 내용을 더 정확히 이해할 수 있는 좋은 질문 같습니다.
다른 분들은 어떻게 생각하는지 궁금하네요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[고종봉]

세미나에는 참석하지 못했지만

저도 알고 있기로는 Rest의 결과로 ajax기술등에 대한 한정은 비약인것 같습니다

최근 rest라고 부르는 것들은 원래의 웹 설계시부터 존재해오다가 최근들어 웹서비스 기술이 대두되면서 soap과 대비되는 표현으로 rest라고 부르는 것으로 알고있습니다

엄밀하게는 restful이라고 하는데 우리말로 풀면 표현적인 방식정도로 해석할수 있는데 웹 메서드의 get post put delete가 흔히 말하는 crud의 형태로 데이터의 처리방식을 그대로 표현한다는 의미로 알고있습니다

초창기 웹에서 위의 네개의 메서드가 모두 존재했었지만 시간이 흐르면서 get post로만 대부분 사용하다보니 퇴행되었다가 다시금 api적 관점에서 그 속성들의 중요성이 거론되고 있습니다

결국 요청의 응답으로 ajax기반의 표현에 제약은 두지않으면 요청의 호출 방식에 주안점을 두는 것으로 알고 있습니다. 브라우저가 아닌 http 클라이언트의 형태로 호출되기 때문에 응답은 xml json등의 통합친화적인 표현을 사용할수 있습니다다

나의 GalaxyS로부터...

2010. 11. 15. 오후 9:13에 "Outsider .." <outsi...@gmail.com>님이 작성:

[찬욱]

오랜만에 메일링에 답글을 작성하네요^^.

Outsider 님의 피드백에 우선 감사드립니다.
말씀하신대로 세미나 발표란 제약을 갖고 있는 상황에 따라 발생한 오해같네요.

우선 요청에 대한 응답을 HTML이냐 XML/JSON이냐를 강조한 것이 아니고, 기존의 처리 방식에서 뷰 처리 방식의 분리를 강
조한 것입니다. 그리고 JSON이나 XML로만 사용할 수 있도록 강제했다는 언급은 한 적이 없습니다.(물론 발표 중에 실언을 했
다면 모르겠지만요..)

더군다나 Ajax를 사용한 코드는 단순한 예제를 보여드린 것으로 이를 기술적인 제약 사항이나 한정으로 제시한 적도 없습니다.

또한 Outsider님 말씀대로 발표 중에 "리소스에 기반을 두어 같은 리소스는 같은 URL을 가지고 액션은 HTTP의
method를 이용해서 구분하는 것이라고 이해하고 있는데.."라는 부분을 분명히 언급해드린 걸로 기억합니다.

기술 세미나에서 REST에 대한 정의부터 시작하기는 처음 접하는 분들에게 오히려 위화감만 준다는 생각으로 발표의 맥락을 구성한
것이기 때문에 기존의 REST에 대해 각자의 생각을 갖고 계신 분들에게는 오해의 소지도 있었으리라 생각합니다.
정의부터 시작해도 마찬가지 문제라고 생각하지만, 맥락을 가지고 설명하려고 했던 부분을 정의로 받아들이시면 어려운 부분일 것 같습
니다. 물론 그렇게 와닿지 않으셨다고 하시면 제 문제겠죠 =_=;

[Outsider ..]

이렇게 빠르게 직접 답변을 주실줄은 몰랐네요.

직접 답변을 주시니까 좀 더 명확해 지는것 같습니다.

정확히 모든 말씀이 기억하고 있지는 않지만 강제했다는 부분은 제가 이해하면서 결론을 내린 부분일수도 있겠습니다. 다만 제가 저렇게 생각한 것은 말씀하신 "뷰의 분리"때문이라고 생각하는데요

발표하시던 당시에 뷰가 없다는 것을 여러번 강조했었던 것으로 기억하고 있습니다.

그때문에 제가 REST는 JSON이나 XML만 된다는 것으로, 혹은 뷰를 분리해야 된다고 설명하시는 것으로 이해를 한 것 같습니다.

그럼 뷰의 분리는 REST를 활용한 하나의 예시로 제시하신 부분이셨던 건가요?

저는 그부분이 REST를 모르는 분들에게는 REST는 그렇게 사용하는 것으로 받아들이지 않을까 하는 생각이 들었던 거였거든요.

저만 그렇게 잘못 이해했을수도 있고요.. ㅡㅡ;;;

늦은 시간에도 답변 감사드립니다.

2010/11/16 찬욱 <chanwo...@gmail.com>

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[Yongsik Jeong]

의견을 천천히 쓰다보니, 찬욱님의 답변이 올라와버렸네요;;

사실 저는 별로 거부감 없이 들었는데요.

저희가 평소에 접하는 RESTful Web service의 정의와 다른 이야기를 하신 것은 맞지만, 크게 오해할 부분은 없었다고 생각했어요.

한시간 안에 많은 내용을 전달하려다 보니 단정적으로 이야기하려 하신 것같긴 하지만, 최근 RESTful 이야기 들으면서 판에 박힌 이야기만 듣다가 '이제 Server에 View는 없다'라는 등의 한걸음 나간 이야기를 들으니 사실 저는 초큼 좋았습니다 :) 

(근데 제가 궁금한 보안이야기는 늘 '더 생각해볼 이야기'에 잠깐 나온단 말이죠;;)

1.

'..json과 XML 형태로 내려주는 것이다' 라는 것에 대해서도 오해가 있는게 아닐까요.

저도 Spring framework에서 html/text 방식을 지원하리라 생각합니다. 하지만, 현재 가장 많이 사용하고 있는 것은 json, XML 형식으로 응답하는 것이구요. RESTful web service를 제공하는 naver, daum, google 등에서도 json, XML을 주로 가끔 text(제가 알기로는 google의 일부 service에서)를 지원합니다. json, XML은 JAXB를 이용해 객체로 쉽게 바꾸고, (key, value) 쌍이나 혹은 유사하게 사용할 수 있는지라 쉽게 이해할 수 있고 대부분의 언어에서 쉽게 변환해서 사용할 수 있지만, text 같은 다른 것은 그리  장점이 안보여서요;

2.

RESTful만을 말한다면 Outsider 님이나 고종봉님의 의견이 맞다고 생각합니다. 한두가지 형태로 구분 짓는 것이 RESTful의 정의와 위반됩니다.  

그런데, 현재의 RESTful Web service를 이야기하면 조금 다른 것 같아요. 어느 정도 틀이 정해져 있거든요.

method는 GET, POST를 사용하고, request는 HTML의 Form 방식으로 보내고, response는 'json, XML'로  받고, response를 받는 client 는 Rich Client로 등등

method의 UPDATE,DELETE를 쓰거나, request를 json, XML 등으로 보내는 RESTful web service를 보게되면 제보좀 해주세요.

구경좀 하고 싶어요.

p.s

거의 다 썼는데, Outsider의 답글도 올라와버렸어요! ㅠ

또 고쳐야 돼;;

어서 많이 알아서 더 빨리 쓰는 사람이 되고 싶군요;

3. 

위의 내용을 이야기 하실 때 과거의  View는 'Client side의 브라우저는 수동적으로 보여주기만 하고, Server에서 보여질 모든 것을 html, jsp, javascript 등으로 만들어서 보냈다', 하지만 현재 RESTful Web service에서의 View는 'Json 이나 XML로 정제된 data만을 보내고, 페이지는 client에서 Server에서 받아온 값을 이용해 능동적으로 보여준다.'라고 말씀하시려던 것 같습니다. 저는 그렇게 이해했구요.

그리고 위와 같은 차이 때문에, 여전히 Server side에 View가 있기는 하지만 모든 페이지를 만들어 주던 과거의 View와는 다르다( = Server Side에는 더이상 예전의 View는 없다.)고 말씀하신 것 같네요. 

2010/11/16 Outsider .. <outsi...@gmail.com>

[Yongsik Jeong]

의견을 천천히 쓰다보니, 찬욱님의 답변이 올라와버렸네요;;

사실 저는 별로 거부감 없이 들었는데요.

저희가 평소에 접하는 RESTful Web service의 정의와 다른 이야기를 하신 것은 맞지만, 크게 오해할 부분은 없었다고 생각했어요.

한시간 안에 많은 내용을 전달하려다 보니 단정적으로 이야기하려 하신 것같긴 하지만, 최근 RESTful 이야기 들으면서 판에 박힌 이야기만 듣다가 '이제 Server에 View는 없다'라는 등의 한걸음 나간 이야기를 들으니 사실 저는 초큼 좋았습니다 :) 

(근데 제가 궁금한 보안이야기는 늘 '더 생각해볼 이야기'에 잠깐 나온단 말이죠;;)

1.

'..json과 XML 형태로 내려주는 것이다' 라는 것에 대해서도 오해가 있는게 아닐까요.

저도 Spring framework에서 html/text 방식을 지원하리라 생각합니다. 하지만, 현재 가장 많이 사용하고 있는 것은 json, XML 형식으로 응답하는 것이구요. RESTful web service를 제공하는 naver, daum, google 등에서도 json, XML을 주로 가끔 text(제가 알기로는 google의 일부 service에서)를 지원합니다. json, XML은 JAXB를 이용해 객체로 쉽게 바꾸고, (key, value) 쌍이나 혹은 유사하게 사용할 수 있는지라 쉽게 이해할 수 있고 대부분의 언어에서 쉽게 변환해서 사용할 수 있지만, text 같은 다른 것은 그리  장점이 안보여서요;

2.

RESTful만을 말한다면 Outsider 님이나 고종봉님의 의견이 맞다고 생각합니다. 한두가지 형태로 RESTful을 정의 내릴 수 없지요.  

그런데, 현재의 RESTful Web service를 이야기하면 조금 다른 것 같아요. 어느 정도 틀이 정해져 있거든요.

method는 GET, POST를 사용하고, request는 HTML의 Form 방식으로 보내고, response는 'json, XML'로  받고, response를 받는 client 는 Rich Client로 등등

method의 UPDATE,DELETE를 쓰거나, request를 json, XML 등으로 보내는 RESTful web service를 보게되면 제보좀 해주세요.

구경좀 하고 싶어요.

p.s

거의 다 썼는데, Outsider의 답글도 올라와버렸어요! ㅠ

또 고쳐야 돼;;

어서 많이 알아서 더 빨리 쓰는 사람이 되고 싶군요;

3. 

위의 내용을 이야기 하실 때 과거의  View는 'Client side의 브라우저는 수동적으로 보여주기만 하고, Server에서 보여질 모든 것을 html, jsp, javascript 등으로 만들어서 보냈다', 하지만 현재 RESTful Web service에서의 View는 'Json 이나 XML로 정제된 data만을 보내고, 페이지는 client에서 Server에서 받아온 값을 이용해 능동적으로 보여준다.'라고 말씀하시려던 것 같습니다. 저는 그렇게 이해했구요.

그리고 위와 같은 차이 때문에, 여전히 Server side에 View가 있기는 하지만 모든 페이지를 만들어 주던 과거의 View와는 다르다( = Server Side에는 더이상 예전의 View는 없다.)고 말씀하신 것 같네요. 

2010/11/16 Outsider .. <outsi...@gmail.com>

이렇게 빠르게 직접 답변을 주실줄은 몰랐네요.

[Outsider ..]

구글 버즈의 API를 보니까 PUT과 DELETE를 쓰도록 되어 있네요.

http://code.google.com/apis/buzz/v1/using_rest.html#delete-activity

http://code.google.com/apis/buzz/v1/using_rest.html#update-activity

역시 구글!!!!

정용식님이 말씀하신 1번 부분은 현재 REST가 주로 뷰가 필요없는 OpenAPI위주로 

사용하고 있기 때문에 그런부분이라고 생각하는데

다들 잘 알아서 이해하셨는데 저만 사소한 부분에 집착하고 있었군요...

깊게 알지 못하다보니 생각이 많은 편이라서요... ㅠㅠ

2010/11/16 Yongsik Jeong <sun...@gmail.com>

[찬욱]

@Outsider 님
네. 제 개인적인 생각으로는 REST가 통용되는 정의가 있지만 말 그대로 '아키텍처 스타일'이기 때문에 아키텍처 적인 제약(=스
타일)을 어떻게 정의하냐에 따라 많은 차이가 있다고 생각합니다.(정의부터 시작하면 이런 추상적인 얘기 중심으로 흘러갈까봐 세미나
에서는 오해의 소지에 불구하고 제한적인 설명 방식대로 할 수밖에 없었다는 스토리가 있습니다^^)

질문해주신 '뷰의 분리'는 제가 말씀드리고 싶었던 일반적인 Spring MVC 기반 정보 시스템과 REST 기반의 정보 시스
템 개발 시에 가장 처음 격게되는 진입장벽(?) 이기 때문에 강조를 할 수 밖에 없었습니다. 뷰를 처리해야 하는 책임이 기존의
서버가 소유하냐, 클라이언트로 넘어가냐에 따라 단순한 기술적인 요소부터 프로그래밍 모델까지 많은 부분을 고민해야 하게 되더라구
요.

아무튼 이렇게 저에게 자극(?)을 주시니 감사드립니다.
좋은 기회가 되서 REST에 대해 논의해보는 시간이 있어도 좋겠네요~
이틀째 밤을 셀 기세라 괜찮습니다^^.
감사합니다.

@Yongsik Jeong
네. 사실 저는 SOAP과 비교하는 REST의 성격보다는 일반적인 MVC 기반의 업무 시스템을 대상으로 제 생각을 말씀드렸기 때
문이라고 생각합니다.
1. 유형 별 처리 방식이나 사례가 공유되면 좋겠죠. 일단 하나 확실히 말씀드릴 수 있는 건 일반 웹에서는 JSON이 정답이
고, 이건 앞으로 HTML5로 넘어가도 마찬가지라는 여러 분들의 의견입니다.
2. (자세한 내용은 언급하기 어려우나..) 저 같은 경우는 4개(UPDATE가 아니라 PUT을 말씀하신 거죠?^^)의 메서드
를 모두 정의하고 사용했습니다. 정의가 모호하기는 하지만 제 개인적인 생각으로는 4개의 메서드를 모두 활용하는 게 명확성을 위해
서 2개의 메서드만 사용하는 것보다 좋은 방법이라고 생각합니다. 이 문제는 검색해보시면 해외에서도 많이 논의 된 사례를 찾으실
수가 있습니다.
요청을 JSON이나 XML로 보내는 건 사례가 없다기보다 당연히 그렇게 해야 한다고 생각합니다. 그래서 제가 발표 중에 (어찌보
면 이 부분이 제일 오해를 살 수도 있지만..) CNVR는 진정한 REST를 위한 기능이 아니라는 말을 했었던 것이구요..
3. 뷰가 분리되기는 했지만, 여전히 페이지를 누군가는 만들어야 한다는 점은 있지만, REST 방식의 리소스 관리가 된다면 서
버와의 연계를 페이지 단위로 고려하는 것과 데이터로 보는 건 성능이나 처리 방식 등에서 많은 차이가 있을 것이라 생각합니다.

좋은 의견 감사합니다^^.

[Outsider ..]

사실 올리기 전에 어떻게 받아들이실지 몰라서 고민을 많이 했는데...

좋게 받아주시니 감사할 따름입니다. ㅎ

제한된 시간내에 무언가를 명확하게 전달하는 건 참 어려운 일이죠..

너무 구체적일수도 너무 추상적일수도 없으니까요...(저에게 발표는 너무 어려운 일이라...)

REST에 대해서 좀더 심도깊은 얘기를 해보고 싶지만

슬슬 제 지식의 한계가 드러나는군요 ㅎㅎㅎㅎ(누가 좀 새로운 논의점을 던져주셔도.. ㅎ)

말씀하셨던 도메인정의에 대한 고민이나 무엇을 리소스로 볼것이냐 하는 부분은

RESTful로 구현을 하다가 포기하기 쉽게 만드는 가장 큰 장벽이 아닌가 싶기도 합니다.

이런 부분에 대해서 한번 논의해 보는 것도 재미있을것 같습니다.

JSON이 짱이라는 부분은 전적으로 동감합니다.(XML 파싱 피곤해요 ㅎㅎㅎ)

2010/11/16 찬욱 <chanwo...@gmail.com>

--

Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[고종봉]

찬욱님께서 빠르고 성실한 답변을 주셔서 어느 정도 내용이 정리된 것 같네요..

오히려 저는 세미나의 내용을 잘 모르고 글을 써서, 괜히 기름만 부은 격이 된거 같아요.ㅎ

이렇게 밤새 진지하고 성실한 답변과 토론이 진행되어 참으로 보기 좋은 것 같습니다.

발표하신 찬욱님께는 여러 가지로 노고를 치하해 드리며(고생 많으셨을 텐데, 오해가 있었다면 죄송합니다),

세미나 참가자와, 성실히 후기 및 질문 해주신 여러 분들께도 박수를 보내드립니다.

짝~ 짝~

2010년 11월 16일 오전 1:27, Outsider .. <outsi...@gmail.com>님의 말:

[Seokhoon Hyeon]

주제와 다른 얘길지도 모르겠으나

그런데 사용자 브라우저가 스크립트 작동이 안된다면?

어떻게 되는거죠

네줄 쓰고 피곤에 쩔어 버렸습니다

나의 iPhone에서 보냄

2010. 11. 16. 오전 5:53 고종봉 <mercu...@gmail.com> 작성:

[Joshua]

1시 넘어서도 댓글을 다시는 분들은 잠은 언제 주무시는지;

저도 4가지 method를 모두 사용하는게 옳다고 생각했으나, 주변에서 샘플이나 같은 의견을 얻지 못했었는데
이렇게 4가지 method를 사용하는게 옳고 하는 사람들도 있다는 이야기도 듣고 샘플도 얻으니 좋군요 :)

모두 좋은 말씀 고맙습니다.

@Seokhoon Hyeon
javascript가 안되니 ajax를 쓸 수 없겠지요?
그러니 json이나 xml 값으로 받는 것이 쓸모가 없지 않을까요?
참, HTML5가 javascript 없이도 무엇인가 할 수 있도록 하려던 것 같던데(이건 제가 잘 몰라서요; 아는 분이 답변
좀 주세요;;),
javascript가 지원안되는 환경이라면 HTML5가 지원되길 기대하는 것도 어렵지 않을까요?

On Nov 16, 7:48 am, Seokhoon Hyeon <151...@gmail.com> wrote:
> 주제와 다른 얘길지도 모르겠으나
>
> 그런데 사용자 브라우저가 스크립트 작동이 안된다면?
>
> 어떻게 되는거죠
>
> 네줄 쓰고 피곤에 쩔어 버렸습니다
>
> 나의 iPhone에서 보냄
>

> 2010. 11. 16. 오전 5:53 고종봉 <mercujj...@gmail.com> 작성:

>
>
>
>
>
>
>
> > 찬욱님께서 빠르고 성실한 답변을 주셔서 어느 정도 내용이 정리된 것 같네요..
>
> > 오히려 저는 세미나의 내용을 잘 모르고 글을 써서, 괜히 기름만 부은 격이 된거 같아요.ㅎ
>
> > 이렇게 밤새 진지하고 성실한 답변과 토론이 진행되어 참으로 보기 좋은 것 같습니다.
>
> > 발표하신 찬욱님께는 여러 가지로 노고를 치하해 드리며(고생 많으셨을 텐데, 오해가 있었다면 죄송합니다),
>
> > 세미나 참가자와, 성실히 후기 및 질문 해주신 여러 분들께도 박수를 보내드립니다.
>
> > 짝~ 짝~
>

> > 2010년 11월 16일 오전 1:27, Outsider .. <outside...@gmail.com>님의 말:

> > 사실 올리기 전에 어떻게 받아들이실지 몰라서 고민을 많이 했는데...
> > 좋게 받아주시니 감사할 따름입니다. ㅎ
> > 제한된 시간내에 무언가를 명확하게 전달하는 건 참 어려운 일이죠..
> > 너무 구체적일수도 너무 추상적일수도 없으니까요...(저에게 발표는 너무 어려운 일이라...)
>
> > REST에 대해서 좀더 심도깊은 얘기를 해보고 싶지만
> > 슬슬 제 지식의 한계가 드러나는군요 ㅎㅎㅎㅎ(누가 좀 새로운 논의점을 던져주셔도.. ㅎ)
>
> > 말씀하셨던 도메인정의에 대한 고민이나 무엇을 리소스로 볼것이냐 하는 부분은
> > RESTful로 구현을 하다가 포기하기 쉽게 만드는 가장 큰 장벽이 아닌가 싶기도 합니다.
> > 이런 부분에 대해서 한번 논의해 보는 것도 재미있을것 같습니다.
>
> > JSON이 짱이라는 부분은 전적으로 동감합니다.(XML 파싱 피곤해요 ㅎㅎㅎ)
>

> > 2010/11/16 찬욱 <chanwook....@gmail.com>

> > 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

>
> > --
> > /************************************************
> > Outsider
> > Front-end & Server-side Developer
>
> > Blog :http://blog.outsider.ne.kr
> > Twitter : @outsider

> > G-Talk : outside...@gmail.com

> > *************************************************/
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

> > 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[Sanghyuk Jung]

가끔 KSUG 분들 중에 너무 열심히 사시는 분들이 계신 것 같아서 좀 무섭기도 해요. ^^;

2010년 11월 16일 오전 7:48, Seokhoon Hyeon <151...@gmail.com>님의 말:

[백기선]

@benelog 그러게요. 아마 요즘은 제가 제일 한가하게 살고 있을껄요. 캬캬캬..

2010년 11월 16일 오전 9:59, Sanghyuk Jung <ben...@gmail.com>님의 말:

--
좋은 하루 되세요~

[Sewon Ann]

세미나에 불참해서 (Y_Y) 찬욱님의 세션을 못 들은 상태에서 궁금한 게 있습니다.

저도 4개 method 를 쓰는게 의미도 명확해서 좋다고 생각하는데, 브라우저에서 GET, POST 만 제대로 지원하는 부분에 대해서 다른 분들은 어떻게 생각하시는 지 궁금합니다.

일부 구현체에서는 별도로 method 를 parameter로 받아서 처리하는 경우도 보았습니다. ( /post/345?method=DELETE 뭐 이런식)

그런데 저런식의 편법까지 동원해서 브라우저에서 지원하지 않는 DELETE, PUT 으로 만드는게 나은지, 우아하진 않지만 어쩔 수 없이 브라우저에서 지원하는 GET/POST 만 지원하는 게 좋은 지 고민이 되요.

물론 4개 method 가 우아해 보이긴 하지만 말이에요.

@전체 문맥에 맞는 질문인지 모르겠네요 ^^;

2010/11/16 백기선 <whites...@gmail.com>

[Sungchul Park]

> 세미나에 불참해서 (Y_Y) 찬욱님의 세션을 못 들은 상태에서 궁금한 게 있
> 습니다.
> 저도 4개 method 를 쓰는게 의미도 명확해서 좋다고 생각하는데, 브라우저
> 에서 GET, POST 만 제대로 지원하는 부분에 대해서 다른 분들은 어떻게 생
> 각하시는 지 궁금합니다.

브라우저가 지원하지 않는 게 아니고 HTML 표준에서 두 가지만 정의하고 있다
고 하는 게 맞습니다. 브라우저는 네가지 모두 지원합니다. 그러니까 HTML이
아닌 방법으로 HTTP 호출을 하면 네가지 모두 사용가능하다는 말이죠. 결국
브라우저에서 해결할 문제가 아니라 HTML 표준을 변경해야 할 문제입니다.

> 일부 구현체에서는 별도로 method 를 parameter로 받아서 처리하는 경우도
> 보았습니다. ( /post/345?method=DELETE 뭐 이런식)
> 그런데 저런식의 편법까지 동원해서 브라우저에서 지원하지 않는 DELETE,
> PUT 으로 만드는게 나은지, 우아하진 않지만 어쩔 수 없이 브라우저에서 지
> 원하는 GET/POST 만 지원하는 게 좋은 지 고민이 되요.
>
> 물론 4개 method 가 우아해 보이긴 하지만 말이에요.

수작업으로 하면 거추장스럽고, 억지스럽지만 spring form taglib같은 기술을
사용해 자동화한다면 의미 있다고 생각됩니다. URL이 훨씬 의미있어지더군요.

[Sewon Ann]

아, 제가 잘 못 알고 있던 부분이네요.

고맙습니다.

http://stackoverflow.com/questions/165779/are-the-put-delete-head-etc-methods-available-in-most-web-browsers

위 링크를 보니 대부분의 XHR 은 4개의 method를 지원하나 보네요.

제가 고민하는 부분은 openAPI 형태의 구성인데,  호출은 (대부분) XHR 를 통해 이뤄지니 아래 논의된 4개의 method를 사용해도 사용하는 측에서 큰 무리가 없겠군요!

2010/11/16 Sungchul Park <gyu...@gmail.com>

--

[SEOK HOON HYEON]

허접하니까...

시간으로 때우고 있는거죠. ㅡ,.ㅡ

2010년 11월 16일 오전 11:36, Sewon Ann <kin...@gmail.com>님의 말:

--
안녕하세요. 현석훈 입니다.
Hi~ My name is HYUN SEOK HOON

[Outsider ..]

HTML5에서는 어떻게 스펙이 변경했나 보려고 

HTML5와 HTML4의 차이점 문서를 찾아보니 http://www.w3.org/TR/2010/WD-html5-diff-20101019/

아래처럼 나와있네요.

Using PUT and DELETE as HTTP methods for the form element is no longer supported.

더이상 PUT, DELETE는 지원안한다고 하네요.(마치 4에서는 지원했던것처럼!!!!)

지원하길 기대했는데 약간 의외군요...

히스토리가 있는지 찾아봐야겠습니다.

@SEOK HOON HYEON

ajax로 동적으로 하는 부분은 Rich한 사용자 경험을 제공하는 부분입니다.

사용자의 브라우저가 JS를 지원하지 않는다 하여도 핵심적인 기능은 동작가능하도록 제작이 되어야 합니다.

기본적인 액션은 모두 할수 있는 상태에서 더 편리한 경험을 제공하기 위해서 사용되어야 합니다.

(머 이론상은 그런데 현실적으로 만만치 않죠.)

2010/11/16 SEOK HOON HYEON <151...@gmail.com>

--

[Sungchul Park]

중요한 질문인데 이어지지 못했네요.

그런데 사용자 브라우저가 스크립트 작동이 안된다면?

어떻게 되는거죠

이미 좋은 가이드가 인터넷이나 책으로 나와있겠지만 제 머릿 속에 있는 놈만 정리해보면

1) 컨텐츠 교섭 방식
한  URL에서 브라우저가 이해할 수 있는 컨텐츠 타입에 맞게 다양한 유형의 컨텐츠를 제공하는 방식입니다. http 헤더의 Accept 류의 헤더를 이용해서 브라우저가 선호하는 유형을 선택해 제공합니다. 이 과정에서 스프링의 ContentNegotiationViewResolver를 쓸 수 있습니다.

2) 컨텐츠 유형 별 URL을 분리 방식

URL별로 반환하는 컨텐츠 유형을 고정시키고 브라우저 측에서 필요한 URL을 호출하도록 하는 방식입니다. 예를 들어 다음과 같은 링크가 있다면

<a href="some_url_returns_html.html" onClick="viewJsonResult(); return false;">click me</a>

스크립트가 작동하는 브라우저에서는 viewJsonResult()가 작동해서 ajax로 처리가 될 것이고 스크립트가 작동 안하는 브라우저에서는 some_url_results_html.html이 호출되겠죠.

3) 서비스를 분리하는 방식

스크립트 작동 방식의 서비스와 순수 HTML 작동 방식의 서비스로 분리해서 따로 제공합니다. RIA 사이트의 경우 이 방식을 사용하게 됩니다. gmail이 예가 되겠네요.

4) 순수 HTML을 지원하지 않는 방식

RIA는 해야겠고 돈은 없고(또는 귀찮고)... 우리 모두가 선택하는... ^^

네줄 쓰고 피곤에 쩔어 버렸습니다

나의 iPhone에서 보냄

2010. 11. 16. 오전 5:53 고종봉 <mercu...@gmail.com> 작성:

찬욱님께서 빠르고 성실한 답변을 주셔서 어느 정도 내용이 정리된 것 같네요..

오히려 저는 세미나의 내용을 잘 모르고 글을 써서, 괜히 기름만 부은 격이 된거 같아요.ㅎ

이렇게 밤새 진지하고 성실한 답변과 토론이 진행되어 참으로 보기 좋은 것 같습니다.

발표하신 찬욱님께는 여러 가지로 노고를 치하해 드리며(고생 많으셨을 텐데, 오해가 있었다면 죄송합니다),

세미나 참가자와, 성실히 후기 및 질문 해주신 여러 분들께도 박수를 보내드립니다.

짝~ 짝~

2010년 11월 16일 오전 1:27, Outsider .. <outsi...@gmail.com>님 의 말:

2010/11/16 찬욱 <chanwo...@gmail.com>

@Outsider 님

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
/************************************************

Outsider

Front-end & Server-side Developer

Blog : http://blog.outsider.ne.kr

Twitter : @outsider

G-Talk : outsideris@gmail.com

*************************************************/

--

Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com 로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com /group/ksug?hl=ko에서 그룹을 방문하세요.