RSS

카테고리 보관물: OpenAPI

무료 https/ssl인증서 startssl 소개

최근에 kt를 사직하고, 작은 스타트업에 합류해서,  웹 서비스를 하나 개발하고 있습니다. 작은 회사다 보니 모든 것을 개발자가 해야하는 특권을 누릴 수 있어 좋습니다. ^^

지난 주에는 ssl인증서를 구매해야 하는데, railscasts에서 소개해준 무료 ssl인증서를 제공하는 startssl를 이용해봤습니다. 후기를 적습니다.

요약:

  1. 무료 ssl 구매 방법 소개
  2. 약 2일 정도 시간이 걸렸음.

startssl.com 은 이스라엘 회사로 웹사이트 인증에 많이 쓰이는 ssl인증서 뿐만 아니라 이메일 보안을 위한 인증서도 발급하는 인증으로 먹고 사는 회사입니다.

startssl.com 홈페이지

startssl.com 홈페이지

 

보통 http로 접속해서 인터넷 사이트를 이용하는데, 인터넷의 모든 정보는 저 멀리 어딘가에 떨어져 있는 웹서버를 통해서 우리 브라우저까지 전해지는데요. 이 데이터가 평문으로 전송됩니다. 이말은 누군가 가로챌 경우에 그 내용이 무엇인지 다 알 수 있다는 것입니다. 보안으로 취약한 것이죠. 특히나 우리가 회원 인증을 위해서 암호를 입력하는데 ******* 이런 식으로 브라우저에 표시되지만 네트워크로 전송될 때는 평문으로 누가 보면 암호를 알아 낼 수 있게 됩니다. 그래서 https 라는 보안 프로토콜을 사용하는 데 이 때 ssl 인증서가 필요합니다.

SSL에 대한 소개 영상 (한글)

생활코딩에서 설명하는 SSL과 https

위 영상을 보면 이해가 될 것 입니다만, 요약하면, 인증서는 공인인증서 같이 이 인증서의 주인이 누구다란 것으로 인증해주고, 웹서버 주인인 서비스 공급자가 자기가 보내는 웹사이트 정보를 암호화 시켜서 보내면, 브라우저에서는 이 웹사이트 주인의 인증서를 인증기관에 조회해서 그 사람의 공개키를 가지고 주인이 암호화한 것을 복호화 시켜 읽게 됩니다.

그런데, 이 인증서를 발급해주고 누군가 이 사이트 주인이 확실하냐라고 물었을 때, ‘그렇다 혹은 아니다’ 이야기 해줄 수 있는 인증기관이 필요한데, ssl인증 기관이 무료로 해주진 않고 소정을 수수료를 받고 1년간 인증해주는 식으로 운영되고 있습니다. 공인인증서 갱신시 돈을 내고 하는 인증서와 같습니다.

그런데 가격이 정해진 것이 아니고 업체마다 다양합니다. 약 100불 정도에 형성되어 있는데, 무료로 제공해주는 startssl.com 같은 독특한 회사도 있습니다.

싼게 비지떡 아니냐하는 반신반의로 시작했고, 이틀에 걸쳐서 인증을 받게 됩니다. 나쁘지 않습니다. 무료 ssl은 StartSSL Free 상품입니다.

철차는 다음과 같습니다.

  1. startssl.com 에 접속해서 내 이메일을 인증 받는다. (이메일 등록하면 메일로 해시키가 전송되고 그럴로 인증함)
  2. 인증하는 과정에서 내 브라우저에 인증서가 설치되고 이것으로 이후 로그인을 하게 됨. (id/pw방식이 아님)
  3. 로그인 후에, 내가 ssl인증을 받고자 하는 domain name을 내가 소유하고 있는지 확인하는 절차를 진행함. domain name owner에게 메일로 해시키를 보내고 그걸 받아서 입력하면 인증됨.
  4. 인증된 domain name을 선택하고 시키는 대로 진행하면 개인키를 생성하고 그에 맞는 인증서를 생성해주는데, 이 때 서브 도메인을 하나 정할 수 있는데, 기본적으로 1차 도메인 즉, example.com 은 ssl인증이 되기 때문에, 2차(서브) 도메인으로 http://www.example.com 을 추가해주거나 api.example.com 중에 하나를 선택하면 될 것이다. 요즘은 웹사이트와 오픈API도 ssl로 서비스하는 경우가 많으므로 웹사이트는 example.com 으로 api서비스는 api.example.com 으로 제공하면 괜찮을 것 같다.

이 방식을 진행할 때, 한번에 쭈욱되는 것은 아닙니다. 이메인 인증하거나 도메인 인증을 할 때에 6시간 정도씩 대기가 필요한 경우가 있으니 적용을 위해서 이틀 정도 시간을 두고 진행하세요.

하나 더 관심이 있을 것 같은데요. 2차 도메인을 여러개 쓸 수 있도록 허용해주는 *.example.com (wild cards) ssl 인증서를 받으려면 StartSSL verified 를 구입하세요. 60불 정도 합니다.

Happy Coding 😉

 

 

 
댓글 3개

게시자: 켬 2014년 5월 28일 in 클라우드, OpenAPI, Uncategorized, web server

 

태그: , , ,

웹사이트의 데이터를 API로~! kimonolabs 소개

업데이트: 2016년 2월 29일을 기점으로 kimonolabs는 서비스를 종료한다고 합니다. 이러한 B2C형태의 API서비스들이 수익모델을 찾지 못하고 서비스를 접게 되는 것은 어떤 의미가 있을까요? 종료 안내 문 링크: https://www.kimonolabs.com

오늘 페이스북에 쓴 글입니다.

얼마전 소개한 적이 있는 kimonolabs의 웹사이트에서 API를 만들어주는 기능을 사용해 봤습니다. 서울시의 25개 구의 대기오염물질의 수치를 알려주고, 종합점수격인 CAI 지표를 출력해주고 상태도 표시해주는 API입니다.

처음 만들었는데, 만드는데 5분도 안걸렸습니다.

http://www.kimonolabs.com/api/7lcmxa14?apikey=0d7e77d3f256eb9502dc9d046b1c6d13

여기 가서 회원가입하고 써보세요. http://www.kimonolabs.com/
베타 기간 중에는 PRO로 모든 기능을 써볼 수 있도록 풀어져 있네요.
이메일로 보내는 기능도 있어서 IFTTT랑 연동하면 특정 조건일 때 다른 행동을 프로그래밍 해볼 수 있을 거 같아요.

요약하면, kimonolabs를 이용하면, 매우 적은 시간으로 웹사이트의 데이터를 기계들이 이해하기 쉬운 정형화된 데이터로 API를 만들어준다는 것입니다.. API는 매우 유연하여, 모바일 앱이나 다른 웹사이트에서 활용하기 쉬운데요. 예를 들어 보면,

서울특별시 대기환경정보 사이트가 있습니다. 시민들이 쉽게 자기 지역의 대기환경정보를 쉽게 볼 수 있도록 다음과 같은 표를 보여주고 있습니다. 다른 공공기관의 데이타들도 형편이 비슷합니다.

2014-03-09 18_00_39-도시대기측정소 측정소별 실시간 오염도 _ 서울특별시 기후대기환경정보

사람들이 읽기 좋게 표에 색상도 넣고 아름답게 구성을 해두었습니다. 하지만 웹사이트 어디에도 기계가 읽기 쉽게 정형화 되어 있는 데이터 API는 찾을 수가 없어 아쉬움이 남는군요. 이럴 때 kimonolabs를 이용하면 JSON 포멧으로 데이터를 뽑아 줍니다. 이런 형태로 보여주는 것이죠.

웹사이트 갱신 주기에 따라서, 비가 오나 눈이 오나 1시간에 한번씩 이 웹사이트에 들어와서 데이터를 읽고나서 JSON으로 변환시켜서 제공해주고 있습니다. 웹사이트가 크게 변화하지 않는 이상 계속 이 API는 유지될 것입니다.

간단히 사용법을 녹화해봤습니다.

공공데이터를 API화 시켜서 여기 공개해주세요.

https://docs.google.com/spreadsheet/ccc?key=0AnpyfRYyrkgzdDQyWjY5T3JRdzFNOWRCdWh2bHQ3V3c&usp=sharing

Happy Coding!

 
댓글 2개

게시자: 켬 2014년 3월 9일 in API Design, 공공정보, 앱개발, OpenAPI

 

태그: ,

공공 데이터 긁어 오기

예전부터 만들고 싶었던, 착한 가게를 소개하는 sns앱에 대해서 진지하게 고민하기 시작한 지, 오늘로 삼일째. 추석 연휴를 보내고 목요일 근무가 제대로 될 리 없었던 차에, 퇴근 직전에 착한 가격 업소를 정부에서 관리하고 있다는 것을 검색을 통해 알게 되었다.

[관련기사] 우리 동네 착한 가격 업소 아세요? 
– 행정안전부, 7,132개 착한가격업소 선정 –

어려운 경제여건에서도 저렴한 가격으로 영업하며 어려운 이웃과 지역사회를 위해 봉사하는 착한가격업소가 전국적으로 7,132개 선정되었다.

(하략)

이런 공공데이터가 있다면 내가 만들고자하는 “착한 가게”의 기초자료로 활용하기 적절하다는 생각에, 살펴보았다. 하지만 좌절스럽게도 open api나 파일형태로 제공되는 데이터는 없었다. 그냥 게시판처럼 목록과 상세 내용이 있는 페이지가 전부라니. 우리나라의 공공정보의 현주소려니 체념하고, 어떻게 데이터를 긁어올 수 있을지 고민해봤다.

공공 데이터 긁어 오기 시작

쿼리 파라미터를 순차적으로 증가시키면 거기에 맞는 상세 페이지가 만들어지는 형태라서, 순차적으로 주소를 호출하고 HTML를 파싱해서 내가 원하는 데이터를 가져오기로 했다.

이 작업을 위해서 레일스를 활용하기로 했다. 가져온 데이터는 기준위치에서 얼마나 떨어져있는지 쿼리가 가능한 MongoDB를 사용한다. 레일스에서 해당 데이터를 긁어 오기 위해서 rake task를 하나 생성했다.  rake는 rails의 make나 ant같은 툴로 특정 task를 코딩해두면 rake 명령으로 실행할 수 있다. task를 정의하는 부분이다.

Nokogiri를 활용한 HTML 파싱

위 코드에서 Nokogiri라는 gem를 사용했는데, XML이나 HTML같은 well-form document에서 xpath를 사용해서 특정 element(태그)나 attritbute로 찾아내고 이동하고 데이터를 추출하는 일련의 기능을 묶어 놓은 것이다. jquery랑 유사한 기능이다. url로 데이터를 가져와서 Nokogiri로 HTML를 파싱한다.

xpath란?

nokogiri를 제대로 활용하기 위해서는 xpath라는 것을 이해하면 좋은데, Michael Kay의 표현을 빌려오자면, xpath란 ‘데이터베이스에서 SELECT가 있다면 XSLT에는 xpath가 있다’ 즉 HTML이라는 document에서 내가 원하는 데이터를 뽑아내기 위한 문법 정도로 이해하고 있으면 되겠다.

위 코드에서 data.phone = doc.xpath(“//th[text()=’전화번호’]/following-sibling::*”).text 부분을 보면 xpath 함수 안에 들어가는 내용이 xpath 문법이다. 풀어 쓰면 “전화번호를 innerText로 갖고 있는 <th> 태그 바로 뒤에 있는 태그들”에 해당된다.

이렇게 어떤 HTML이나 XML이라 하더라도 xpath를 잘 정의해두면 특정 데이터를 쉽게 가져올 수 있을 것이다. 행안부의 착한 가격 가게 페이지가 아닌 다른 어떤 페이지라고 하더라도 xpath의 내용만 고침으로 필요 데이터를 가져올 수 있게 되었다.

Nokogiri와 xpath의 도움으로 몇 줄안되는 코딩으로 해당 HTML에서 우리가 원하는 데이터를 선택하고 그것을 MongoDB에 담는 데 까지 성공했다. 이제 반은 성공한 셈이다.

주소를 좌표로 바꿔보자

지오코딩

일반적으로 geocoding란 주소나, 우편번호등의 데이터에서 longitude, latitude로 대표되는 좌표계의 경위도를 찾아내는 것이다. 그 반대로 좌표에서 주소를 찾아내는 것은 리버스 지오코딩이라고 한다. 우리는 행안부의 자료에서 착한 가격 가게들의 주소를  이미 받아왔다. 이제 이 주소에 해당되는 좌표가 어떻게 바뀌게 되는지 살펴보려고 한다.

다음 open api중 지역 API를 활용

다음의 open api중에 지역 API를 활용하면 정확한 주소를 입력했을 때, 경위도를 뽑아준다. 심지어 새주소 체계에서도 잘 동작한다. 이를 활용하려면 다음 계정으로 로그인한 상태에서 API 키를 발급받아야 하는데, 매우 간단히 신청이 가능하고 즉시 활성화된다. 제한이 있다면 하루에 이 API를 호출할 수 있는 횟수가 3만번으로 제한되어 있다는 것이다. 우리의 주소데이터가 약 6천개이므로 3만번이면 나쁘지 않다.

이 코드에서 지오코딩이 어떻게 일어나는 지 볼 수 있다. 주소를 받아서 그 주소를 API의 쿼리 파라미터에 넣어 보낸다. 물론 개인적으로 받은 api_key를 함께 보내야 제대로 동작한다. 그런데 그렇게 주소를 요청했지만 데이터를 못받는 경우도 있다. 그러면 주소에서 맨 뒤 어절을 지우고 재귀호출을 한다. 그런식으로 뒤의 상세 주소를 지워감으로 주소가 모호해지고 그러면 API에서 위치를 받아오는데 성공할 수 있게 된다. 좀 어려운가? 예를 들면, “서울시 마포구 공덕동 14-1 2층 서울약국” 이런 주소로 쿼리했을 때 결과값이 오지 않는다면 서울약국을 떼고 “서울시 마포구 공덕동 14-1 2층”으로 요청해본다. 그래도 안되면 2층을 떼낸다. “서울시 마포구 공덕동 14-1” 이렇게 보내면 거의 성공하게 된다. 혹시 주소가 없는 경우라면 14-1도 떼버린다. 그러면 공덕동의 어디 쯤의 좌표를 돌려주게 되어 모호해지긴 하지만 데이터는 받게 되는 것이다. 이런 식의 heuristic 접근이 상당히 유용했다. 재귀호출을 한 것도 코드의 복잡도를 낮춰줘서 괜찮은 아이디어였던 것 같다. 🙂

이렇게 어렵게 얻어온 경위도 좌표는 MongoDB에 잘 저장되었고 이제 소기의 목적을 달성한 것으로 보인다.

남은 작업

이제 남은 작업은, 이 DB에 접근하기 위한 API wrapping layer를 하나 만들어 주고, 그것 호출해서 사용할 iOS, Android 앱을 만들면 되는 것이다. 이번 프로젝트에 Titanium을 써보려고 한다. 과연 어느 정도까지 자유도를 줄 수 있을 지 네이티브 iOS개발자로서 무척 기대된다.

 
댓글 2개

게시자: 켬 2012년 10월 6일 in 공공정보, 앱개발, OpenAPI, rails

 

태그: , , , ,

REST API설계에 도움이 되는 링크 모음

최근 LBSNS 아임IN 시즌2 개발하면서, Restful API를 설계하면서 다른 곳에서는 어떻게 하고 있는지 찾아보고, 비평하며, 배우고 있습니다.

제 경우는 Rails를 익히고 있던 터라, 사실 대부분의 Resource 설계에 대한 지식은 Rails route 쪽 문서를 통해서 익혔습니다.

Rails Routing from the Outside In

이 문서는 Rails에 대한 기본적인 컨셉을 알고 있는 분들에게 유용할 것입니다만, 그렇지 않더라도 Resource에 대한 실제적인 설명을 보고 싶은 분들에게 추천하고 싶습니다.

저는 “Restful api라면 Rails처럼” 이라고 줄여서 표현하고 싶을 정도입니다.

REST관련 서적이 Ruby로 구현된 점도, Rails개발자들이 REST API에 영향을 주고 받고 있다는 증거인지 모르겠습니다.

Apigee라는 회사에서 설계 관련 문서를 자주 무료 ebook형식으로 내놓고 있습니다. 이들의 이야기도 볼 만합니다. API 컨설팅을 해주면서 익혔던 교훈을 가볍게 소개하고 있습니다. 분량도 적어 빨리 볼 수 있습니다.

이 중에서 두 문서를 추천합니다. (다운 받으려면 간단한 폼을 작성해야 하더군요)

  • Is Your API Naked? – API 로드맵이라는 부제에 걸맞게 API관련 일반적인 토픽을 다루고 있습니다.
  • Web API Design – API설계할 때 구체적으로 필요한 내용들을 다룹니다. (한글 의역)
Apigee의 동영상도 하나 링크합니다. 무려 1년이나 된 동영상이지만, REST API에 대한 통찰을 전해줍니다. 즐감하세요~!
Atlassian에서 자신들의 앱에 REST API를 추가할 때, 가이드 라인을 제시하고 있습니다.
Atlassian REST API Design Guide Part 1 (누가 아틀라시안 아니랄까봐, 아주 복잡한 이야기 그대로 쓰고 있습니다 ^^)
유명 서비스들 REST API 페이지
이건 재미로, “내 아내에게 REST를 설명했던 방법“이란 블로그 포스트 한국어로 번역되지 않았는데, 심심할 때 한번 번역해보면 좋을듯. 🙂
apigee의 webinar인데 시간이 많으신 분들은 한 번 들어보세요.
미물님의 좋은 API 설계란 무엇인지 다루는 포스트 “Web API Design: 개발자에게 사랑받는 API만들기”
더 유용한 글이 보이면 이 페이지에 더 추가해 놓겠습니다. 추천해주세요~! 🙂
(to be update… )
 
댓글 9개

게시자: 켬 2012년 5월 8일 in API Design, OpenAPI

 

태그: , , , ,

테이블 뷰에 네트워크 요청을 붙여보자

들어가며

UITableViewController 만큼이나 사랑받는 UI가 없을겁니다. 많은 정보를 가볍게 보여 주는 놀라운 UI이지요. 테이블 뷰에 data source에 해당되는 NSArray형의 모델의 내용을 cellForRowIndexPath에서 구현해주는 것이 일반적입니다.

 

해결하고자 한 문제

그런데, 이 모델을 채워넣는 방식이 로컬의 자료가 아닌 원격의 서버를 통해서 데이터를 가져오는 경우라면, 소위말하는 (open) API를 통해서 JSON이나 XML 형태의 데이터를 http 프로토콜로 넘겨받는 패턴입니다.

이런 패턴을 “Online Data source UITableViewController Pattern” 이라고 정의 해봤습니다.

 

구현 방법

이런 패턴을 구현하기 위해서 저는 UITableViewController의 category를 만들었습니다.

@interface UITableViewController (NSURLConnection) <ApiProtocol>

– (void) requestWithURL:(NSURL*) url;

@end

requestWithURL 메소드를 통해서 특정 API를 요청하게 되고 그 결과를 NSURLConnection으로 받아옵니다.

받아온 data를 JSON Serialization으로 NSDictionary나 NSArray형으로 리턴되도록 만든 예제입니다.

github를 통해 다운 받으면 iOS 5용 프로젝트가 나옵니다. 실행시켜보면 뉴욕타임즈의 베스트셀러 API를 요청하고 그 결과값을 JSON으로 받아 테이블 뷰에 그려주는 단순한 앱이 실행됩니다.

실행화면 스크린샷입니다.

다운로드

주의! 소스코드에 포함된 NYTimes API키는 테스트 용도로만 사용해주세요. 감사합니다.

 
댓글 남기기

게시자: 켬 2011년 12월 22일 in iOS개발, OpenAPI

 

태그: ,

우리나라의 공공정보

필자는 정보가 공공재라는 생각을 예전부터 가졌지만, 요즘들어 더욱 관심을 갖게 된 것은 몇 해 전부터 잊을만하면 다시 듣게 되는 정부2.0같은 IT와 접목된 공유의 방법의 전환이라는 트랜드 때문이다.

공유의 방법이 바뀌어도 참 많이 바뀌었다. 정보가있는 기관을 찾아가서 보던 방식에서 웹을 통한 조회가 과거와 현재의 방법이었다면, 공개API(어플리케이션 프로그래밍 인터페이스)를 통하여 공개됨으로 개발자나 개발사에서 누구나 쉽게 그 정보를 재가공하여 전달할 수 있는 기회를 갖게 되었다.

예컨데, 공공도서관의 책 정보를 생각해보자. 예전에는 도서관에 직접 가서 사람과 사람이 만나서 책 정보를 검색했었다. 그 후에 터미널이나 웹이란 게 생겨서 원격으로도 필요한 책을 검색해볼 수 있었다. 즉 컴퓨터와 사람이 만난 것이다. 그런데 최근의 변화는 API라는 프로그래밍 규칙에 의해서 책 정보를 컴퓨터와 컴퓨터사이에 주고 받을 수 있게 되었다. 이제 컴퓨터 프로그래머들은 공공정보의 공개API의 힘을 빌려서 자신의 목적에 부합하는 어플리케이션을 만들 수 있고 그것을 공유하여 다른 사람들에게 까지 가치를 전달할 수 있게 된 것이다.

최근 스마튼 폰의 보급이 천만대를 넘어서면서, 어플리케이션(이하 앱스, apps) 개발자들도 많아졌다. 이들은 저마다 창조성을 발휘하여 가치있는 앱스를 만들고 있는데 공공정보가 공개API형태로 제공된다면, 이들이 개발하는 앱스에서 쉽게 공공정보를 가져다가 유용하게 사용할 수 있을 것이다. 가령, 스마트폰 유저는 자신의 현재 위치에서 가장 가까운 곳에 위치한 공공도서관의 책을 찾을 수 있게 되는 것이다.

우리나라는 2009년도 말부터 앱스 붐이 일기 시작했다. 아이폰을 위시하여 수많은 스마트폰들이 출시되었고, 자연스레 앱스 개발도 활성화 되었다. 하지만, 우리나라의 공공정보의 제공 수준은 이런 스마트폰 혁명과는 전혀 다른 나라에 와있는 듯, 질과 양의 모두 낮은 수준에 머물러 있다. 필자는 최근에 우리나라의 공공정보의 양과 질이 어떠한지 알아보기 위해서 기사와 웹사이트를 검색해봤다. 대표적인 공공정보에 대한 사이트로 공공정보 활용 지원센터와 서울시 모바일 공공정보 OpenAPI 였다.

공공정보 활용 지원센터는 양적인 측면에서는 서울시의 모바일 공공정보에 비하여 더 많았지만 해당 공공정보가 API형태로 제공되지 않고 단순히 해당정보를 관리하는 주무부처의 일관되지 않는 웹서비스 형태로만 지원되고 있었다. 이것은 정보공개를 수행하는 표준이 없는 상태에서 각 사업자들의 자신들만의 방식으로 웹서비스를 만들었기 때문이라고 생각한다. 이런 표준이 없는 이유는 아직도 정보공개에 대한 우리의 시민의식의 현주소 때문일 것이다.

서울시 모바일 공공정보 OpenAPI는 표방한 이름처럼 OpenAPI를 염두에 두고 공공정보 제공 사업을 진행하고 있었다. 하지만 제공하는 정보의 종류가 7종에 불과한 초보적인 단계에 머물고 있다.

나눌 때에 비로소 가치가 부여되는 공공정보가 누군가에 의해 빗장이 꼭꼭 걸어잡긴 채 곰팡이만 쓸고 있는 게 씁쓸한 현실이다. 국가 재정, 복지, 인권 등에 대한 시민들의 감시를 위해서는 팩트(fact)가 필요한데 그것에 대한 접근을 매우 어렵도록 방조하는 정부는 부도덕한 정부다. 또 팩트를 있는 그대로 전달하지 않고 자신의 입맛에 맞게 변질 시키는 정치인, 정당, 언론등도 부도적하기는 매한가지다. 다행이도 IT의 힘으로 정보를 다루는 기술은 매우 발전했다. 이제는 팩트를 공유하고 그것을 객관적으로 분석하는 일이 양식있는 시민들이라면 큰 힘을 들이지 않고서도 할 수 있는 범위의 일이 되었다.

정부2.0을 구지 언급하면서 거창하게 이야기 하지 말고, 각론으로 들어가서 공공재로서의 정보를 어떻게 수집하고 관리하고 공유할 지에 대한 구체적인 논의가 시민사회에서 또한 정부에서 진행되길 기대해보며 어리석은 글을 마무리한다.

최피디 드림

 
댓글 한 개

게시자: 켬 2011년 4월 19일 in OpenAPI

 

태그: ,

KR Domain 검색 OpenAPI

한국인터넷진흥원(KISA)에서 OpenAPI를 지원한다는 기사를 보고 평소에 오픈API에 호기심이 많았던 제가 사용해보려고 신청을 했습니다. 누구든지 이메일과 사용목적만 채워서 신청 하면 API를 사용할 수 있는 것 같습니다. 하지만 키가 발급되니 과도한 사용에 대해서는 규제가 될 수 있겠습니다.

제공하는 API는 한종류로  Whois OpenAPI 입니다. kr로 끝나는 도메인을 검색해서 누가 등록했는지 정보를 XML형식으로 리턴해줍니다. 이 API를 이용해서 KR 도메인을 검색해주는 페이지를 하나 만들어 봤습니다.

요즘은 JSON을 주로 쓰시는거 같던데, 여기는 XML로 내려주는 게 좀 아쉬웠습니다. JSON으로 주면 좋겠다는 생각이 간절하더군요.

그래서 gateway역할을 하는 놈을 하나 만들었습니다. 🙂

whois 요청을 하면 json으로 내려주는 앱스입니다.

사용법은 간단합니다.

post나 get방식으로 key, domain_name을 채워서 request하면 json으로 response해줍니다.

요청할 주소는, http://social-tools.appspot.com/whois.json 입니다.

key는 당연히 KISA에서 받으셔야 합니다. domain_name은 abc.kr 이런 식으로 kr로 끝나는 도메인이어야 합니다.

필요하신 분들은 맘껏 쓰시기 바랍니다. 😉

최피디 드림

 
댓글 남기기

게시자: 켬 2011년 4월 18일 in 100LoC, OpenAPI, Python

 

태그: , , ,