JSONP Proxy

간만에 (마음의) 여유가 좀 생겨서 이것저것 하고 놀고 있습니다. 조금 전에는 간단한 JSONP Proxy를 만들어 봤어요. (검색해보니 이미 비슷한게 몇 개 있긴 했지만 그러면 또 뭐 어때요 ㅎㅎ)

JSONP란 XMLHttpRequest의 "same origin policy"라는 보안 정책을 회피하여 다른 사이트와 통신을 할 수 있게 해주는 트릭으로, 야후!나 구글의 Javascript API들이 사용하는 방식입니다. 문제는, 해당 사이트에서 JSONP 형식의 응답을 주어야만 그사이트를 호출할 수 있다는 점인데, 간단한 Proxy를 통해 모든 응답을 JSONP 형식으로 바꿔주게 만들어봤습니다.

http://jania.pe.kr/u/jsonp.cgi?url={url}&callback={callback}&charset={charset}
  • {url} 부분에 원하는 사이트의 주소를 넣으시고(http 포함),
  • {callback} 부분에는 호출이 완료되었을 때 실행될 자바스크립트 함수 이름을 넣고,
  • {charset}은 응답 문자열의 문자셋을 적어주시면 됩니다. 생략하면 utf-8으로 지정됩니다.
예를들어,
  1. function c(json) {
  2.    alert(json.content);
  3. }

  4. var script = document.createElement("SCRIPT");
  5. script.src =
  6.    "http://jania.pe.kr/u/jsonp.cgi?" +
  7.    "url=http://www.google.com&callback=c"
  8. document.body.appendChild(script);
와 같이 쓰시면, 구글 홈페이지의 HTML이 자바스크리트 alert을 통해 화면에 출력됩니다.

이런 작은 장난감들을 몇 개 모아서 Pipe&Filter 방식으로 조합해서 가지고 놀면 재밌는걸 많이 만들 수 있을 것 같아요.

뭘 하고 놀면 재밌을까요? :-)
신고
글작성 중 위키피디아, 구글 검색하기에 이어서, 글 작성 중 편집 중인 단락의 키워드를 실시간으로 추출해주는 예제를 만들었습니다:



야후의 키워드 API를 활용했습니다. 하루에 5,000번 호출 제약이 있어서 캐싱을 하도록 했는데, 캐시에 메모리 제한이 없어서 아마 오래 실행하고 있으면 메모리 릭이 발생할 것 같습니다. 뭐 Xquared 확장성 테스트용 프로토타입이니깐... ㅎㅎㅎ

http://jania.pe.kr/xwriter 에서 직접 써보실 수 있습니다(만, 한글은 분석이 안된다는. --; )

에, 이번에는 이용한 API는
입니다.
신고

JSON 2와 Javascript 2

며칠 전에 JSON 라이브러리(Javascript Object Notation)새 버전이 나왔습니다.

여러 사람들이 환영하는 분위기 입니다. 가장 큰 이유는 기존 버전과 달리 더이상 Object.prototype에 JSON 관련 메서드를 추가하지 않는다는 점입니다. Object.prototype에 뭔가를 추가했을 때의 가장 큰 문제는 모든 객체에 대한 for ... in 루프에서 추가된 속성들이 열거(enumerate)된다는 점이죠.

물론 모든 for ... in 루프에서 다음과 같이 방어적 코딩을 하면 문제될 것은 없습니다만:
for (key in object) if (object.hasOwnProperty(key)) {
    // do something here
}
이 컨벤션이 그리 널리 사용되지 않는다는게 문제죠. Prototype.js 같은 유명한 라이브러리에서 JSON 관련 코드를 다시 만든 이유도 바로 이것입니다. Prototype.js 에서는 Object.prototype을 건드리지 말 것을 강력하게 주장하고 있습니다.

Crockford가 애초에 Object.prototype을 확장하는 방식으로 JSON 라이브러리를 구현한 이유는 바로, JSON 관련 메서드가 다음 버전의 자바스크립트 스팩에 포함되길 원했기 때문입니다.

JSON2가 더 이상 Object.prototype을 건드리지 않도록 바뀐 이유는 어쩌면 현재 자바스크립트 표준(ECMAScript 3rd edition)의 개정판인 자바스크립트 2(ECMAScript 4th edition)에 이미 그의 의견이 반영되었기 때문일지도 모르겠습니다.

(은근슬쩍 Javascript 2 얘기로 넘어갑니다)

그렇다고 해서 Crockford가 ECMAScript 4th edition을 좋아한다는 것은 아닙니다. 사실 그는 ECMAScript 4th edition (final draft)의 무지막지한 변화들(PDF)에 반대하고 있죠. 그가 생각하는 자바스크립트의 가장 큰 장점 중 하나는 1999년(3rd edition) 이후 언어 스팩에 어떠한 변화도 없었다는 사실이니까요. 한편, Javascript의 창시자인 Brendan은 Crockford가 뒤에서 4th edition 험담을 하고 다니는 걸 별로 달가워하지 않는 것 같습니다.

저도 final draft를 한번 훑어 읽어봤는데... 솔직한 느낌은
  • 이런 저런 언어들에서 좋다고 하는 것들은 다 넣고
  • 양념으로 실험적인 특징들 몇 개 추가
  • 그러면서도 여전히 자바스크립트로 남아 있기 위해 물려받은 유산(legacy)들을 가진
그런 언어가 됐다는 느낌입니다. 어떤 이는 "more like Java but better"라고 "긍정적으로" 표현하고 있지만, 또 다른 어떤 이는 그 표현이 "worse but better"로 들린다고 하는군요 ㅎㅎ 저도 사실 약간 그렇게 들립니다.

뭐 그래도 스팩 상에 문제 없고, 스팩대로 구현만 깔끔하게 잘 나와준다면(이런 식은 곤란), 쓰는 사람이 알아서 잘 골라쓰면 되는 것이긴 하니까요.
신고
< Newer     Older >

티스토리 툴바