사용할 때와 사용하지 않아야 할 때를 분간하기

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 이 페이지를 이메일로 보내기  제안 및 의견 피드백

난이도 : 중급

Brett McLaughlin, Author and Editor, O'Reilly Media Inc.

2006 년 12 월 19 일

평범한 Ajax 개발자들도 Ajax 단어에 있는 x가 XML.을 의미한다는 것 정도는 알고 있습니다. XML은 가장 인기 있는 데이터 포맷들 중 하나이고, 실제로, 비동기식 애플리케이션에서 서버 응답에 효력을 발휘합니다. 이 글에서, 서버가 XML로 된 응답을 보내는 방법을 설명합니다.

XML을 통하지 않고서는 중요한 프로그래밍을 수행할 수 없다. XHTML로 옮기려고 하는 웹 페이지 디자이너, JavaScript로 작업하는 웹 프로그래머, 전개 디스크립터와 데이터 바인딩을 사용하는 서버 측 프로그래머, XML 기반 데이터베이스를 분석하는 백엔드 개발자..등 이 모든 사람들은 이 확장성 있는 마크업 언어를 사용한다. 이쯤 되면, XML이 Ajax를 지탱하고 있는 핵심 기술로 간주되는 것쯤은 놀랄 일도 아니다.

하지만, Ajax 애플리케이션에서 사용되는 핵심 객체(XMLHttpRequest)의 의미를 생각해 봐야 한다. 대부분의 사람들은, XMLHttpRequest 객체가 실제로 언제나 XML을 사용한다고 생각하기 때문에, XML을 Ajax의 핵심 부분으로 생각한다. 이는 사실이 아니며, 그 이유를 밝히는 것이 이 글의 목적이다. 사실, 대부분의 Ajax 애플리케이션에서, XML이 거의 나타나지 않는다.

XML은 Ajax에서 사용되고, XMLHttpRequest는 이를 허용한다. XML은 서버로 보내질 수도 있다. 이 시리즈의 이전 기술자료들에서, 플레인 텍스트와 이름/값 매개변수들을 사용하여 데이터를 보냈지만, XML 역시도 사용 가능한 포맷이다. 이 글에서는, 그 사용 방법을 설명할 것이다. 요청 포맷으로 XML을 사용하는 이유를 설명하고, 대부분의 경우 XML을 사용하지 말아야 하는 이유를 설명하겠다.

XML: 너무나 작은 의미?

Ajax 애플리케이션과 XML의 사용에 대해 추측하기란 쉽다. 기술의 이름(Ajax)과 이것이 사용하는 핵심 객체(XMLHttpRequest)를 보면 XML이 사용되고 있음을 짐작할 수 있고, Ajax 애플리케이션과 XML을 연결 지어 말하는 이야기도 듣게 된다. 그러나, 이러한 인식은 잘못된 것이고, 특히, 비동기식 애플리케이션을 작성할 경우라면, 이러한 인식이 왜 그릇된 것인지를 알아야 한다.

XMLHttpRequest: 의미와 HTTP

기술적인 문제에 발생할 수 있는 가장 나쁜 일은 이것인 너무 굳어져서 기본적인 부분을 변경하는 것이 불가능할 경우가 있다. Ajax 애플리케이션에서 사용되는 기본 객체인 XMLHttpRequest에서도 이 같은 일이 발생한다. 이것은 HTTP 요청을 통해서 XML을 보내거나, 일종의 XML 포맷으로 HTTP 요청을 만드는 것처럼 여겨진다. 객체 이름이 어떤 뉘앙스를 풍기든 상관없이, 이것은 실제로 클라이언트 코드(대게 웹 페이지에 있는 JavaScript)가 HTTP 요청을 보낼 수 있는 방식을 제공한다. 이것이 전부이다. 더 이상 어떤 것도 없다.

따라서, XMLHttpRequest의 이름을 HttpRequest나 간단히 Request 같이, 보다 정확한 단어로 바꾸는 것도 좋을듯하다. 하지만, 수 백만 명의 개발자들이 Ajax에 뛰어들었고, 대다수의 사용자들이 Internet Explorer 7.0이나 Firefox 1.5같은 새로운 브라우저 버전으로 이동하는데 수년이 걸린다는 알고 있기에, 이름을 변경하는 것은 사실상 불가능하다.

XMLHttpRequest를 지원하지 않는 브라우저(특히 Windows)를 다룰 때, 대체 시스템으로는 Microsoft IFRAME 객체를 사용한다. XML, HTTP, 심지어 request 라는 뉘앙스는 어디에서도 풍기지 않는다. 확실히, XMLHttpRequest 객체는 XML이나 HTTP 그 자체 보다는, 페이지 리로드 없이 요청을 할 수 있는 것 이상의 의미를 풍긴다.

요청은 XML이 아니라 HTTP이다.

자주 실수하는 부분 중에, XML이 막후에서 사용된다고 생각하는 것이다. 사실, 나도 그랬다. 하지만, 이 같은 견해는 이 기술을 잘 이해하지 못함을 증명하는 것이다. 사용자가 브라우저를 열고, 서버에서 웹 페이지를 요청할 때, http://www.google.com 또는 http://www.headfirstlabs.com를 타이핑한다. http://를 타이핑 하지 않아도 브라우저는 브라우저 주소창에 그 부분을 채울 것이다. http://는 통신이 어떻게 이루어지는지를 알려주는 단서이다. 바로 HTTP, Hypertext Transfer Protocol을 통한 통신이다. 여러분이 웹 페이지에 코드를 작성하여 서버와 통신할 때, Ajax든, 평범한 형식의 POST이든, 하이퍼링크이든 간에, 무조건 HTTP이다.

HTTPS도 HTTP이다. 웹에 생소한 사람이라면 https://intranet.nextel.com 같은 URL이 낯설 것이다. https는 보안 HTTP이고, 일반 웹 요청에 사용되는 HTTP 프로토콜에서 보다 안전한 형식을 사용하는 것뿐이다. 따라서, HTTPS에 추가 보안 레이어가 추가되었더라도 HTTP와 통신할 수 있다.

브라우저와 서버간 모든 웹 통신은 HTTP를 통해 이루어진다고 할 때, XML은 XMLHttpRequest에 의해 사용되는 전송 또는 기술이라는 개념은 이치에 맞지 않는다. XML이 HTTP 요청으로 보내질 수 있지만, HTTP는 매우 정교하게 정의된 표준이다. 요청에 XML을 명확하게 사용하거나, 서버가 XML로 된 응답을 보내지 않는 한, XMLHttpRequest 객체에서 사용되는 것은 평범하고 오래된 HTTP 뿐이다. 따라서, "막후에서 XML을 사용하기 때문에 이것이 XMLHttpRequest로 호출되었다” 라고 말하는 사람이 있다면, HTTP가 무엇인지, XML이 HTTP를 통해 보내질 수 있고, XML은 전송 프로토콜이 아닌 데이터 포맷이라는 점을 친절하게 알려줘야 한다.

위로

XML 사용하기

지금까지는, XML이 Ajax에 사용되지 않는다는 것을 증명했다. 하지만 Ajax의 x와 XMLHttpRequest의 XML은 무엇을 말하는가? 웹 애플리케이션에서 XML을 사용할 수 있는 여러 옵션들이 있다. 이 섹션에서는 기본 옵션들을 자세히 검토해 보겠다.

XML용 옵션

비동기식 애플리케이션에서, 두 개의 기본적인 XML 애플리케이션이 있다:

• 웹 페이지에서 서버로 웹 페이지 포맷으로 된 요청 보내기
• 서버에서 온 요청을 XML 포맷으로 웹 페이지에서 받기

첫 번째 항목인, XML로 된 요청을 보낼 때는 요청을 XML로 포맷팅 해야 한다. API를 사용하거나 텍스트를 연결하여 그 결과를 서버로 보내는 것이다. 이 옵션에서, 기본적인 작업은 XML 규칙에 순응하는 방식으로, 그리고 서버가 이해할 수 있도록 요청을 만드는 것이다. 이 부분에서의 초점은 XML 포맷이다. 보낼 데이터가 있다면, 이를 XML 문법으로 래핑해야 한다. 이 글 나머지 부분에서는 Ajax 애플리케이션에서의 XML 사용에 대해 설명하겠다.

두 번째 옵션인, XML로 된 요청을 받을 때에는, 서버에서 응답을 가져다가, XML에서 데이터를 추출해야 한다. (API나 다른 방식을 사용한다.) 이 경우, 서버에서 온 데이터에 집중하여, XML에서 데이터를 가져와서 이를 사용한다. 이 부분은 다음 기술자료의 주제이다.

경고

XML 사용법을 자세히 설명하기 전에, 한가지 주의를 주고 싶다. XML은 작고, 빠르며, 공간 절약형 포맷이 아니다. 다음 여러 섹션들과 다음 기술자료에서 보겠지만, 어떤 정황에서 XML을 사용해야 하는 몇 가지 이유가 있고, XML이 플레인 텍스트 요청과 응답보다 더 나은 점도 갖고 있다. 하지만, XML은 플레인 텍스트 보다 더 많은 공간을 차지하고, 더 느리다. XML에 필요한 포든 태그와 문법을 메시지에 추가해야 하기 때문이다.

매우 빠른 애플리케이션을 작성하고 싶다면, XML은 올바른 선택이 아니다. 플레인 텍스트로 시작하고, 특정 부분에서 XML이 필요할 경우, 그때 XML을 선택하는 것이 좋다. 하지만, 처음부터 XML을 사용한다면, 애플리케이션의 반응이 늦어진다. 대부분의 경우, 다음과 같이 텍스트를 XML로 전환하는 것 보다는 name=jennifer 같은 이름/값 쌍을 사용하여 플레인 텍스트를 보내는 것이 더 빠르다:

<name>jennifer</name>

XML을 사용하면 시간이 오래 걸리는 모든 상황을 생각해 보자. 텍스트를 XML로 래핑(wrap)할 때, 추가 정보(실제 요청의 일부인 주변 엘리먼트, XML 헤더 등은 포함하지 않았다.)를 통해 보낼 때, 서버에서 XML을 파싱하고, 응답을 만들고, XML로 응답을 래핑하고, 이것을 다시 웹 페이지로 보낼 때 페이지에서 응답을 파싱하여 이를 사용할 때 등이 있다. 따라서, XML을 사용해야 할 때를 배우고, 많은 상황에서 애플리케이션을 빠르게 실행하려는 생각으로 시작해서는 안된다.

위로

XML을 클라이언트에서 서버로

포맷으로서 XML을 사용하여 클라이언트에서 서버로 데이터를 보내는 방법을 보자. 우선, 기술적인 관점에서 그 방법을 규명하고, 어떤 것이 좋은 생각인지를 검토해보자.

이름/값 쌍 보내기

여러분이 작성하는 웹 애플리케이션의 90퍼센트 정도가 이름/값 쌍을 서버로 보낸다. 예를 들어, 사용자가 이름과 주소를 웹 페이지의 폼에 입력하면, 폼에서 다음과 같은 데이터를 얻는다:

firstName=Larry
lastName=Gullahorn
street=9018 Heatherhorn Drive
city=Rowlett
state=Texas
zipCode=75080

서버로 보낼 데이터에 플레인 텍스트를 사용하면, Listing 1과 같은 코드를 사용한다. (본 시리즈의 첫 번째 글에 사용했던 예제와 비슷하다. (참고자료)

				
function callServer() {
  // Get the city and state from the Web form
  var firstName = document.getElementById("firstName").value;
  var lastName = document.getElementById("lastName").value;
  var street = document.getElementById("street").value;
  var city = document.getElementById("city").value;
  var state = document.getElementById("state").value;
  var zipCode = document.getElementById("zipCode").value;

  // Build the URL to connect to
  var url = "/scripts/saveAddress.php?firstName=" + escape(firstName) +
    "&lastName=" + escape(lastName) + "&street=" + escape(street) +
    "&city=" + escape(city) + "&state=" + escape(state) +
    "&zipCode=" + escape(zipCode);

  // Open a connection to the server
  xmlHttp.open("GET", url, true);

  // Set up a function for the server to run when it's done
  xmlHttp.onreadystatechange = confirmUpdate;

  // Send the request
  xmlHttp.send(null);
}

이름/값 쌍을 XML로 변환하기

다 음과 같이, 데이터용 포맷으로서 XML을 사용하고 싶다면, 데이터를 저장한 기본적인 XML 포맷을 따라야 한다. 이름/값 쌍은 모두 XML 엘리먼트로 바뀔 수 있고, 여기에서 엘리먼트 이름은 그 쌍에서 이름이 되고, 엘리먼트의 콘텐트는 값이 된다:

<firstName>Larry</firstName>
<lastName>Gullahorn</lastName>
<street>9018 Heatherhorn Drive</street>
<city>Rowlett</city>
<state>Texas</state>
<zipCode>75080</zipCode>

물론, 여러분은 루트 엘리먼트를 갖거나, 단순히 문서 조각 (XML 문서의 일부)으로 작업하는 것이라면, 인클로징(enclosing) 엘리먼트가 필요하다. 위 XML을 다음과 같이 변환한다:

<address>
  <firstName>Larry</firstName>
  <lastName>Gullahorn</lastName>
  <street>9018 Heatherhorn Drive</street>
  <city>Rowlett</city>
  <state>Texas</state>
  <zipCode>75080</zipCode>
</address>

이제 웹 클라이언트에 구조를 만들고, 이것을 서버로 보낼 준비가 얼추 되었다.

구두상의 통신

네 트워크를 통해서 XML을 전달하기 전에, 데이터를 보낼 서버, 그리고 스크립트가 XML을 실제로 받아들이는지를 확인해야 한다. 물론 여러분에게는 이렇게 말하는 것 자체가 미안하지만, 신참 프로그래머들은 네트워크를 통해서 XML을 보내면 올바르고 받아서 인터프리팅 되는 것으로 착각하기도 한다.

여러분이 보내는 XML로 된 데이터가 올바르게 수신되도록 하기 위해서는 두 단계를 거쳐야 한다:

1. 전송할 스크립트가 데이터 포맷으로서 XML을 수락하는지를 확인한다.
2. 스크립트가 여러분이 보내는 데이터의 특정 XML 포맷과 구조를 수락하는지를 확인한다.

이 두 단계 모두 사람들과 실제로 이야기 해봐야 한다. XML로 데이터를 보내는 것이 중요한 문제라면, 스크립트 라이터는 여러분에게 그렇게 할 것을 명령할 것이다. XML을 받아들일 스크립트를 찾는 것은 어려운 일이 아니다. 하지만, 여러분이 가진 포맷이 스크립트가 기대하고 있는 것과 맞는지를 확인해야 한다. 예를 들어, 서버가 다음과 같은 데이터를 받아들인다고 하자:

<profile>
  <firstName>Larry</firstName>
  <lastName>Gullahorn</lastName>
  <street>9018 Heatherhorn Drive</street>
  <city>Rowlett</city>
  <state>Texas</state>
  <zip-code>75080</zip-code>
</profile>

두 가지를 제외하고는 위 XML과 비슷해 보인다:

1. 클라이언트에서 온 XML은 address 엘리먼트 내에서 래핑되지만, 서버는 데이터가 profile 엘리먼트 내에서 래핑될 것을 기대하고 있다.
2. 클라이언트에서 온 XML은 zipCode 엘리먼트를 사용하지만, 서버는 집 코드가 zip-code 엘리먼트에 있을 것을 기대하고 있다.

데 이터를 수락하고 처리하는 서버와 페이지를 엉망으로 만들 서버는 이 작은 차이로 만들어진다. 따라서, 여러분은 서버가 기대하고 잇는 것이 무엇인지를 파악하고, 데이터와 포맷을 혼합해야 한다. 그리고 나서야, 클라이언트에서 서버로 XML을 보낼 수 있는 기술을 다룰 준비가 되는 것이다.

서버로 XML 보내기

서 버로 XML을 보낼 때, 데이터를 실제로 전송하는 것 보다, 데이터를 취해서 이를 XML로 래핑하는데 코드 작업을 더 많이 해야 한다. 사실, 서버로 보낼 준비가 된 XML 스트링이 있다면, 다른 플레인 텍스트를 보내는 것과 똑같이 보낸다. Listing 2에서, 이것이 어떻게 작동하는지를 보자.

				

function callServer() {
  // Get the city and state from the Web form
  var firstName = document.getElementById("firstName").value;
  var lastName = document.getElementById("lastName").value;
  var street = document.getElementById("street").value;
  var city = document.getElementById("city").value;
  var state = document.getElementById("state").value;
  var zipCode = document.getElementById("zipCode").value;

  var xmlString = "<profile>" +
    "  <firstName>" + escape(firstName) + "</firstName>" +
    "  <lastName>" + escape(lastName) + "</lastName>" +
    "  <street>" + escape(street) + "</street>" +
    "  <city>" + escape(city) + "</city>" +
    "  <state>" + escape(state) + "</state>" +
    "  <zip-code>" + escape(zipCode) + "</zip-code>" +
    "</profile>";

  // Build the URL to connect to
  var url = "/scripts/saveAddress.php";

  // Open a connection to the server
  xmlHttp.open("POST", url, true);

  // Tell the server you're sending it XML
  xmlHttp.setRequestHeader("Content-Type", "text/xml");

  // Set up a function for the server to run when it's done
  xmlHttp.onreadystatechange = confirmUpdate;

  // Send the request
  xmlHttp.send(xmlString);
}

코드만 봐도 충분히 설명되지만, 몇 가지 중요한 포인트가 있다. 우선, 요청 데이터는 XML로 직접 포맷팅 되어야 한다. Document Object Model을 사용하는 방법을 설명한 세 개의 기술자료를 읽어서 그런지 약간 실망한 것 같다. JavaScript를 사용하는 XML 문서를 만들기 위해 DOM을 사용하지 말란 법은 없지만, GET 또는 POST 요청으로 네트워크를 통해서 이것을 보내기 전에 DOM 객체를 텍스트로 변환해야 한다. 따라서, 일반적인 스트링 조작을 통해 데이터를 포맷팅 하는 것이 훨씬 더 쉽다. 물론, 에러와 타이핑 실수가 있을 수 있으므로, XML을 다루는 코드를 작성할 때 특별히 주의를 기울여야 한다.

XML을 구현하면, 텍스트를 보낼 때와 거의 같은 방법으로 연결을 구축한다. 나는 XML에 POST 요청을 사용하는 것을 더 좋아한다. 어떤 브라우저는 GET 쿼리 스트링에 길이 제한을 두고, 게다가 XML은 길이가 매우 길어질 수 있기 때문이다. 따라서 Listing 2는 GET에서 POST로 변환되었다. 게다가, 여러분이 요청한 URL의 끝에 고정된 매개변수로서가 아닌, send() 메소드를 통해 XML이 보내진다. 이 모두가 매우 사소한 차이이지만 조절하기 쉽다.

하지만, 완전히 새로운 코드를 작성해야 한다:

xmlHttp.setRequestHeader("Content-Type", "text/xml");

이해하기 어렵지 않다: 평이한 이름/값 쌍이 아닌 XML로 보낼 것을 서버에 명령하고 있다. 두 경우 모두, 데이터를 텍스트로 보내지만, 여기에서는 text/xml을 사용하거나 플레인 텍스트로 보내진 XML을 보낸다. 이름/값 쌍을 사용한다면, 이 라인은 다음과 같이 읽힌다:

xmlHttp.setRequestHeader("Content-Type", "text/plain");

XML로 보낼 것을 서버에 명령하지 않으면 문제가 생길 수 있다. 그러므로 주의하기 바란다.

여기까지 다 했다면, 이제는 send()를 호출하고 XML 스트링으로 패스해야 한다. 서버는 XML 요청을 받게 되고, (여러분이 사전 작업을 수행한 상태라면) XML을 수락하여, 이를 파싱하고, 응답을 보낸다. 몇 가지 코드가 변경된 XML 요청이 전부이다.

위로

XML 보내기: 좋은 것인가, 나쁜 것인가?

XML 요청 전에, 요청에 XML을 사용하는 문제에 대해 생각해 보자. 앞서 언급했듯이, XML은 전송의 관점에서 볼 때 가장 빠른 데이터 포맷일 뿐, 그 이상도 이하도 아니다.

XML은 구현이 간단하지 않다.

요청에 사용할 XML은 구성하기가 쉽지 않다. Listing 2에서 보듯, 데이터는 XML 문법으로 인해 빠르게 복잡해진다:

var xmlString = "<profile>" +
  "  <firstName>" + escape(firstName) + "</firstName>" +
  "  <lastName>" + escape(lastName) + "</lastName>" +
  "  <street>" + escape(street) + "</street>" +
  "  <city>" + escape(city) + "</city>" +
  "  <state>" + escape(state) + "</state>" +
  "  <zip-code>" + escape(zipCode) + "</zip-code>" +
  "</profile>";

그렇게 심각한 문제는 아니지만, XML은 단 여섯 개의 필드를 갖고 있다. 여러분이 개발 할 대부분의 웹 폼들은 10개에서 15개의 필드를 갖고 있다. 모든 요청에 Ajax를 사용하지 않더라도, 중요한 문제이다. 실제 데이터만큼 많은 대괄호와 태그 이름들을 처리하는데 많은 시간을 허비해야 하고, 오타의 가능성도 크다.

또 다른 문제는 XML을 직접 구현해야 한다는 점이다. DOM 객체를 요청으로 보낼 수 있는 스트링으로 전환하는 것은 간단한 방법이 아니므로, DOM을 사용하는 것은 좋지 않다. 따라서, 이와 같이 스트링으로 작업하는 것이 최고의 방법이다. 하지만, 관리하기 어렵고, 새로운 개발자들이 이해하기 힘든 방식이기도 하다. 이 경우, 한 줄로 모든 XML을 만들었다. 여러 단계에 걸쳐 이를 수행하면 상황은 더 복잡해진다.

XML은 요청에 어떤 것도 추가하지 않는다.

복잡성 문제 외에도, 요청에 XML을 사용하면 플레인 텍스트와 이름/값 쌍 보다 더 나은 점도 없다. 이 글의 초점은, 이름/값 쌍을 사용하여(Listing 1) 보냈던 데이터를, XML을 사용하여 보내는 것에 맞춰져 있다. 플레인 텍스트를 사용하여 보낼 수 없는 것을 XML을 사용하여 보낼 수 있다라고 말하는 것이 아니다. 플레인 텍스트를 사용하여 보낼 수 없는 것을 XML을 사용한다고 해서 가능해지는 것은 결코 아니기 때문이다.

이것이 XML과 요청의 본질이다. 여기에 중요한 이유는 없다. 다음 글에서는, 플레인 텍스트를 사용할 때 다루기 어려웠던 몇 가지 사안들을 XML로 해결하는 방법에 대해 설명하겠다. 오직 XML만 받아들일 것을 스크립트에 명령하지 않을 것이라면, 거의 모든 요청 상황에서 플레인 텍스트를 사용하는 것이 더 낫다.

위로

맺음말

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

Ajax 에서 XML의 의미에 대해 감이 잡혔으리라 생각한다. Ajax 애플리케이션은 XML을 사용할 필요가 없고, XML은 데이터 전송에 있어서 만병 통치약도 아니라는 것도 이제 알게 되었다. 웹 페이지에서 서버로 XML을 보내는 것에도 익숙해졌을 것이다. 서버가 요청을 처리하고 응답을 보낼 때 어떤 것들이 개입되어 있는지도 알게 되었다. 서버 스크립트가 XML을 허용하도록 하고, 데이터를 보내려면 여러분이 사용하는 포맷으로 이를 수락해야 한다.

요청용 데이터 포맷에 XML이 좋은 선택이 아니라는 이유도 알았다. 다음 글에서는, XML이 효과적인 경우와, 대부분의 요청에서는 모든 것을 느려지게 만들고, 복잡해진다는 사실을 알게 될 것이다. 이 글에서 배운 것을 직접 실행에 옮겨 보고, 매우 신중히 수행할 것을 말해주고 싶다. XML 요청은 Ajax 애플리케이션에서 역할이 있지만, 그 역할은 여러분이 생각하는 것만큼 크지 않다.

다 음 글에서는, XML을 사용하여 서버가 응답하는 방법, 웹 애플리케이션이 응답을 처리하는 방법을 설명하겠다. 서버가 XML을 웹 애플리케이션으로 돌려보내는 경우가 많기 때문에 자세한 기술적인 부분들까지 배우게 될 것이다. 지금까지는, 요청을 보낼 때 XML이 좋은 선택이 아닌지를 이해하는 것으로 충분하다. 요청용 데이터 포맷으로서 XML을 사용하여 웹 애플리케이션을 구현하고, 이를 다시 플레인 텍스트로 변환하여, 어떤 것이 더 빠르고 쉬운지를 파악할 수 있다. 다음 글을 기대해주기 바란다.

기사의 원문보기

• Mastering Ajax, Part 7: Using XML in requests and responses

참고자료

• Ajax 마스터하기 시리즈
  
  
• XML: 한국 developerWorks XML 존 기술자료
  
  
• xml.com
  
  
• "동적 자바 애플리케이션 구현 (한글)" (Philip McCarthy, 한국 developerWorks, 2005년 9월): Ajax를 이용한 웹 애플리케이션 구현
  
  
• "Ajax용 자바 객체 직렬화 (한글)" (Philip McCarthy, 한국 developerWorks, 2005년 10월): Ajax 애플리케이션에서 데이터를 직렬화 할 수 있는 다섯 가지 방법
  
  
• "Call SOAP Web services with Ajax" (James Snell, developerWorks, 2005년 10월)
  
  
• DOM Home Page
  
  
• DOM Level 3 Core Specification
  
  
• ECMAScript language bindings for DOM
  
  
• "Ajax: A new approach to Web applications" (Jesse James Garrett , Adaptive Path, 2005년 2월)
  
  
• developerWorks technical events and webcasts
  
  
• 한국 developerWorks 웹 개발 존
  
  

• Head Rush Ajax, Brett McLaughlin (O'Reilly Media, 2006)
  
  
• Java and XML, Second Edition (Brett McLaughlin, O'Reilly Media, Inc., 2001)
  
  
• JavaScript: The Definitive Guide (David Flanagan, O'Reilly Media, Inc., 2001)
  
  
• Head First HTML with CSS & XHTML (Elizabeth와 Eric Freeman, O'Reilly Media, Inc., 2005)
  
  
• IBM 시험판 SW
  
  

• developerWorks 블로그
  
  
• Ajax forum on developerWorks

필자소개

		Nextel Communications에서는 복잡한 엔터프라이즈 시스템을 구현했고, Lutris Technologies에서는 애플리케이션 서버를 개발했다. O'Reilly Media에서는 기고 및 편집 활동을 하고 있다. 베스트 셀러 작가인 Eric과 Beth Freeman과 공동 집필한 Head Rush Ajax는 Ajax에 혁신적인 Head First 방식을 취하고 있다. 그의 신간 Java 1.5 Tiger: A Developer's Notebook은 최신 자바 버전을 다룬 첫 번째 책이며, 그의 고전 Java and XML은 자바 언어에서 XML을 사용하는 방법에 대한 바이블로 통하고 있다.