Feeds:
댓글

Posts Tagged ‘openapi’

www.programmableweb.com 에 게재된 Article을 소개 합니다.

API 사업 발전에 있어서 가장 중요한 개발자에게 어떻게 시선을 맞출지에 대한 얘기 입니다.

저자는 Flickr(사진공유) , Twilio (음성전화,문자) API Doucments 를 예로 들어 설명하고 있습니다.

 

[ API Console / API Browser / API Explorer ]

Image

API를 보급(?)하기 위하여 개발자가 쉽게 API를 이해하고 개발에 사용할 수 있는 대화형 API Console을 언급합니다. 물론 코드를 바로 따서 쓰는 구조도 갖고 있어야 하겠죠.

이 기능은 모든 개발자가 매우 선호하는 방식이며, 주렁주렁 달린 설명보다 효과적임을 강조하고 있습니다. (포스팅 하며 살펴보니 Flickr는 App Garden 이라고 활용사례 위주로 대체된듯 합니다.)

 

[ API Examples – 비즈니스 단위로 단계적 설명 필요 ]

Image

API를 쉽게 개발자에게 이해시키기 위한 방법으로 비즈니스적 접근을 강조합니다.

음성전화,SMS API 설명하기 위한 전화받기, 걸기, 문자 보내고 받기 등등으로 실제로 개발자가 원하는 업무 단위를 중심으로 Documents를 작성할 것을 권고하고 있습니다.

같은 관점에저 Flickr API 설명을 보니 Upload Photo 만 보이는 군요.  세부적인 사진검색, 인증 등은 덜 돋보이도록 배치되어 있습니다.

 

[API 사업 발전과 신뢰]

API 사업의 발전을 위해서는 API와 개발자간의 신뢰가 구축되어야 하며, 사업 담당자는 API Documents에서 정확한 기능을 제시하고 가능한 것과 안되는 것의 명확한 제시를 유지해야 함을 강조하고 있습니다.  물론 세부적인 설명도 필수 이겠지요.

개발자(API 사업관점에서는 파트너)에게 친숙한 샘플 App과 Toubleshooting, Sample codes등도 상호 신뢰를 구축하기 위한 좋은 도구로 제시되고 있습니다.

시사점 : 고객의 눈높이에서 항상 고민하고 Best Practice 를 항상 살펴보자~~~

 

원   문 : http://blog.programmableweb.com/2012/01/09/more-partners-less-effort-api-documentation-for-the-win/

번역본 : http://forum.withapi.com/?document_srl=3921

Advertisements

Read Full Post »

http://www.programmableweb.com/

상기 사이트는 웹관련 API 디텍터리 서비스를 제공중인 사이트 이며,  4,000여개의 API가 게재 되었다고 합니다.

4,000여개의 API가 어떻게 쌓여왔으며, 앞으로의 증가 추이와 관련된 의견을 정리합니다.

상기 그림에서 보듯이 18개월 —> 9개월 –> 6개월 단위로 1,000여개씩 추가되고 있습니다.  이 글을 옮겨 쓰는 2012년 1월 이면 조만간 5,000 API 달성 포스트가 작성되고 있을수도 있겠군요.

페이스북 API는 8개의 API로 Social 분야를 점령하고 있으며, 구글 API도 90여개의 API를 제공중 입니다.

저는 사용하지 않지만 Google Hangout (그룹영상통화서비스) 서비스용 API가 구글+ API와 분리하여 제공중이며,  동영상 분야 또한 스마트 TV와 더불어 이슈가 될 API로 주목하고 있습니다.  1년전 100개의 동영상 API가 150개로 급증했다고 언급하고 있습니다.

또다른 분야로 Commerce API를 언급하고 있습니다.  상기 그림처럼 전통적인 API가 구매행위를 제외한 단순기능 (상품소개, 이벤트 등)에서 구매 자체가 앱 자체에서 정리되는 Commerce API가 현재의 추세라고 합니다.

200개 이상의 API가 이미 등록되어 있으며 더 많은 전자상거래가 활성화 될수록 더욱더 많은 API가 추가될 것이라고 예상하고 있습니다.  심지어 오프라인 매장에서 전자기기 구매행위가 Best Buy API를 사용하는 앱으로 결재하는 날이 올것이라는 선언까지 합니다.  물론, Groupon 쿠폰일수 있겠죠 ^^

마지막으로 여행 API 입니다.  전체 4,000여개의 API 중에서 100개 가량이 있으며 기존의 폐쇄적인 시스템 구조로 아직까지 API화 되지 않았지만 이미 Open API 대세이므로 많은 API가 추가될 것으로 예상하고 있습니다.

여러분들이 예상하시는 Social API 다음의 트렌드는 무엇일까요?   Commerce ?  Travel? and more?

Read Full Post »

저자 : 토비 세가란

발행일 : 2008/04/30    ISBN : 978-89-7914-562-5 93000

파이썬 프로그램을 하게 해준  책이며,  이론을 설명한 후에 짤막짤막한 소스들(파이썬)로 설명한 기능을 완성시켜 가보는 재미가 담겨있는 책입니다.

제목 그대로 집단지성을 프로그램 하기 위하여 Open API를 통한 대형 사이트(?) 의 정보를 접근하여 다양한 분석을 할 수 있는 책자입니다.

쉽게 관련된 유사한 Open API를 찾고자 여기에 정리 합니다.  세부 구현사항은 책자를 참조하시기를….

[목차]

1. 집단지성 소개

2. 추천 시스템 만들기

3. 군집발견

4. 검색과랭킹

5. 최적화

6. 문서필터링

  • 활용예 : 스팸필터링 등
  • 분석기 (단어별 통계)
  • 분류기 (웹기반 서비스의 일부)
  • 피셔방식 (Fisher method)
  • 학습정보의 저장과 복원  (python SQLite)
  • 블로그 피드( http://feedparser.org )  필터링
  • akismet (www.skismet.com)
  • workdpress.com 에서 사용중 (http://kemayo.wordpress.com/)에서 akismet.py 필요

7.의사결정트리

  • 트리학습 (CART 알고리즘 사용)
  • 재귀적 트리 구현
  • 트리의 출력
  • 주택가격 모델링 : http://www.zillow.com/  –> 지역별 부동산 매물정보 , 실내사진이 비교적 잘 정리되어 있는
  • 인기도 모델링 : http://dev.hotornot.com/  –> 헐벗은(?) 총각/처녀들이 점수 딸려구 사진 올리는…

8. 가격모델링

  • 오홋 경매물건의 최종 경매가격을 예측하는 시스템?
  • kNN (k-nearest neighbors) : 가장 비슷한 몇개의 가격을 기반으로 대충 같을거야 라고 가정
  • 물품별 유사도의 계산
  • 물품별 가중치 적용
  • 교차검증 : 학습세트(95%)와 테스트세트(5%)로 구성
  • 이베이 : http://developer.ebay.com/quickstartguide  : 이런 정도의 데이터는 써줘야…

9.고급분류기법 : 커널 기법과 SVM (Support Vector Machine)

10.독립특성발견

  • 다양한 뉴스 기사에서 독립적인 특성 찾기
  • 핵심 주제를 파악하여 한개 이상의 주제를 갖는 기사, 또는 여러 기사에 적용된 주제 추출
  • 으으 행렬의 곱과 전치행렬이…
  • 야후 금융에서 미국 주식시장의 거래량 분석

11. 진화지성

  • 유전자 프로그래밍 (generic programming)
  • 축적된 데이터를 교배, 돌연변이 등등을 가미하여 발전시키기
  • 인공지능형 게임 프로그램 만들기

12. 알고리즘 요약

부록 이거 중요하군요..

Read Full Post »

KTH 로컬플랫폼팀 김수보, 최숭

에버노트 API는 간단한 입력만으로 API KEY 요청 프로세스( http://www.evernote.com/about/developer/api/ )를 통하여 신청이 가능하며, Web Service를 위한 OAuth 인증과 클라이언트 Application 에서 사용 가능한 username/password 인증으로 구분하여 API KEY 신청이 가능하다.

약 40MB로 구성된 SDK( http://evernote.s3.amazonaws.com/api/evernote-api-1.19.zip )에는 android/, as3/, cocoa/, cpp/, csharp/, java/, javame/, perl/, php/, python/, ruby/ 등의 다양한 플랫폼에서 개발에 사용할 수 있는 예제, 소스, 라이브러리가 포함되어 있으며, 본 리뷰는 웹서비스 API 위주로 정리한다

< EverNote API 기본 정책 >

  • 개발자 인증키 등록후 API 사용가능
  • 사용 제한 : 사전공지 없이 제한할 수 있음

< EDAM(Evernote Data Access and Management) 구성 >

Evernote API는 Thrift service definition language인 Apache Thrift (ver 0.4.0:incubator)를 사용한 EDAM (Evernote Data Access and Management) protocol을 사용한다.

EDAM API는 다음의 2개 부분으로 구성되며 각각은 Thrift IDL 파일들로 구성되어 있다.

  • Data Model ( Types.thrift,  Errors.thrift,  Limits.thrift )
  • Remote Procedure ( UserStore.thrift,  NoteStore.thrift )

 < 기본사용방법 >

UserStore의 API 인증결과로 생성된 authentification_string 으로 NoteStore의 API를 사용하며, NoteStore의 API는 Note, Notebook(Note들의 그룹, 폴더)을 관리하는 API와 검색, 태그, 리소스 (gif, jpeg, png, wav, mpeg, amr, pdf, evernote.lnk), 동기화를 관리하는 API로 구성되어 있다.

 

 < UserStore API 구성 >

UserStore API는 5개로 구성되어 있으며, authenticate API에 evernote 계정정보와 API KEY를 사용하여 인증을 시도하며, 인증성공후 결과는 auth_string으로 NoteStore의 API에서 사용됨

refreshAuth는 기본 24시간으로 제공되는 인증기한을 연장할 때 사용하며, checkVersion을 사용하여 현재 어플리케이션 정보를 전송하여 evernote service에서 지원중인 버전인지 확인할 것을 권고하고 있다.

< NoteStore API 구성 >

NoteStore의 API는 인증된 사용자의 Notebook, Note 목록의 관리를 위한 API로 구성되어 있으며, Note의 경우 삭제단계를 2단계 (delete: trach로 이동, expunge: 완전삭제)로 구성하여 현재 evernote UI 환경과 일치한다.

평소 사용해보지 않은 shareNote, LinkedNotebook 기능도 지원되고 있음을 확인할 수 있다.

Note는 물론 Notebook, tag, resource등은 evernote 에서 생성되는 GUID(globally unique ID)를 사용하여 구분되며, 인증정보를 포함한 URL정보만으로 직접 접근이 가능한 구조를 지원하고 있다.

 < Struct: Notebook (Note 폴더) >

Note들의 그룹정보를 관리하는 Notebook 구조는 배포여부를 포함하고 있으며, API 내에서는 서비스의 생성, 업데이트로 설명되고 있다.  예를 들어, 어썸노트등에서 폴더단위로 생성된 노트들이 Evernote로 동기화 할 때 “[aNote]어썸노트폴더명”으로 구분되어 폴더 정보를 유지하고 있다.

  • GUID: string – globally unique identifier
  • name: string
  • updateSequenceNumber: i32
  • defaultNotebook: boolean
  • serviceCreated: UTC Time
  • serviceUpdated: UTC Time
  • publishing: <Publishing>
  • published: Boolean
  • stack: string
  • sharedNotebookIds: list<i64>

 < Struct: Note >

Note들의 실제 정보가 게재되며 tag, resource 정보가 함께 관리된다.

  • GUID: string – globally unique identifier
  • title: string
  • content: string – XHTML Block
  • contentHash: string – MD5 checksum
  • contentLength: i32
  • created, updated, deleted – TimeStamp: UTC Time
  • updateSequenceNumber: i32
  • active: Boolean
  • notebookGuid: string
  • tagGuid: list<Guid> – a list of GUID identifiers for tags
  • tagNames: list<string> – createNote()
  • resources: list<Resources> – embedded resources list
  • attributes: NoteAttributes

< 부가항목 >

Evernote API 에는 상기 Type : Note, Notebook struct 이외에도 20여가지의 Type들이 존재하며 문서 뒤쪽 부록에 하기 정보 관련사항도 비교적 자세히 언급되어 있음.

  • ENML : Evernote Markup Language : 에버노트 데이터의 XML Definition
  • Evernote Recognition Index XML Format : 리소스 특정 타입에서 컨텐츠 추출
  • Note Links 구성 : evernote://view/user id/shard id/note guid/client specific id/[linked notebook guid]

 < 시사점 >

1. 에버노트는…

드미트리 부사장이 한 말입니다.

‘우리는 작은 회사다. 더 많은 기능을 이용자에게 제공하기 위해서는 외부 개발사의 도움이 필요하다.’

‘에버노트는 서비스가 아니라, 플랫폼을 지향한다.’

즉. “저장된 기억을 중심으로 다양한 서비스를 잇는 플랫폼이 되겠다.”는 뜻이라고 합니다.

현재 75명으로 이루어져 있다고 하는군요.

전체 이용자가 1,100 만명 정도 되는데, 약 20%정도가 유료회원으로 전환한다고 하는군요.

한 달에 최소 5달러 요금은 쓰니까, 매월 최소 11억원 정도 들어오는 셈이군요.

가입자가 1달에 100만명씩 늘어난다고 하니, 1년 후에 어떤 기업이 될지는 불을 보듯 명확하군요.

물론 기반 기술은 클라우드입니다.

http://ktsysop.blogspot.com/2011/08/blog-post_406.html

http://www.hani.co.kr/arti/economy/economy_general/490449.html

 

2. 어썸노트 + 에버노트

이 조합이 에버노트를 가장 잘 대변하는게 아닐까 생각되어집니다.

현재 5800만명의 개발자가 가입되어 있으며, 관련 서비스가 188개라고 합니다.

개발자 지원프로그램을 강화하면서, 보급에 나섰는데요. http://v.daum.net/link/15919593

이미 국내 개발사 몇 곳을 만났다고 합니다.

이 부분은 제휴네트워크를 강화하는 것이 API 비즈니스에 얼마나 중요한가를 알 수 있습니다.

현재 14개 언어로 지원하고 있고, 미국 36%, 일본 30%, 유럽 14% 등 나라별로 이용률이 유사한 점으로 보았을 때, 개발자 네트워크를 강화하는 것이 얼마나 중요한지 알 수 있을 것 같습니다.

그리고, 전체 이용자 중 75%가 맥-윈도우 등 멀티플랫폼에서 활용하고 있다고 하니, ‘Global’을 지향하면서 ‘멀티플랫폼’도 같이 지향하는 것은 당연한 수순인 듯 합니다.

3. 기술적 시사점

1)     scalable cross-language platform 인 Apache thrift (http://thrift.apache.org/) 를 적용. (thrift는 facebook 이 개발하여 apache가 incubation하는 프로젝트입니다.)

2)     thift가 version 0.4 (현재 0.61)임에도 불구하고 과감히 적용하는 것은 꽤 배워둘만한 시사점입니다.(사실은 많은 고민을 통해서) à 스토리 : http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift/

3)     (스토리 요약) 2008년의 Evernote는

–       Cross-platform : 현재 Server side java, client side WIN32(윈도우모바일) C++, Obj-C Cocoa로 코딩되어 있었다.

–       Binary Efficienct : Client가 수많은 데이터를 Sync 시킬 수 있는데, 우리는 15MB 대역폭에 맞게 15MB정도로 전송해줄 수 있는 API가 필요했다.

–       Forward/backward compatibility : 우리가 데이터모델을 확장할 때마다, Client 가 변경되길 원하지 않았다.

–       Native bindings : 우리는 모든 Client에서 코드를 파싱하거나 컨트롤하게 하고 싶지 않았다. 보통 이 과정에서 에러가 많이 생긴다.

–       Standard-y and/or open-source : 우리는 일상적인 이유로 상용 제품에 우리 서비스 API를 lock 시키고 싶지 않았다.

–       Not gigantic : 모든 모바일 클라이언트에 200개 class를 가진 1MB 런타임을 탑재하고 싶지는 않았다.

4)     어떻게 바꾸었나?

–       Cross-platform : thrift server stub 구조에 맞게 데이터 구조를 정비함

–       Binary Efficienct : 데이터 필드를 1MB로 유지하게끔 정의 (유선에서 1MB단위로 전송되게끔 유도)

–       Forward/backward compatibility : Thrift 가 빛난 곳 !!! 서비스를 방해하지 않고, 구조나 필드, 서비스 메소드를 추가할 수 있다.

–       Native bindings : Thrift 는 Object-C cocoa 를 지원하고 있지 않아서, 우리 Mac 기술자 1명이 Thrift 컴파일러에 Object-C compiler를 추가했다.

–       Standard-y and/or open-source : 페이스북이 Thrift 를 아파치에 준 것은 정말로 만세하고 싶다.

–       Not gigantic : Thrift runtime은 작고 쉽다.

5)     GUID가 컨텐츠에서 url 로 Direct 접근이 가능하게끔 체계를 잡아 두어서, 매쉬업하기 좋게 만들었습니다.

6)     Resource Type 을 Simple 하게 해서, 다양한 컨텐츠 타입이 수용되도록 했습니다. (모든 것을 메모하겠다는 의지?)

7)     “오픈소스”를 가져다 쓰고, 오픈소스 그룹에서 “활동을 하는 부분”들이 사내에서 당연시 되거나 했으면 합니다. “오픈소스”를 가져다 쓰는 것도 힘들지만, 같이 활동하지 않으면 심도 있는 기술적 도움을 적시에 얻기 힘들더군요. Mailing-list가 중요한 것 같습니다.

Read Full Post »