3. Things Every Developer Should Know...
● Two APIs – REST API / Search API
● Call Limit
● 1000 total Updates/Day
● 250 total DM/Day
● 150 API request/Hour
● HTTP-based, Restful
● Special Parameters
● callback
● suppress_response_codes
4. Things Every Developer Should Know...
● Pagination limits
● REST API : 3200 status
● Search API : 1500 status
● Encoding
● HTML entities
5. 인증방식
●
Basic Authentication
● HTTP 기본적인 인증방식
● 어플리케이션이 비밀번호를 저장하거나 읽어야 함 .
● Base64 인코딩을 하나 , 네트워크에 패스워드가 노
출
● 공식블로그의 blogcocktail@twitter 에서 이 방식 사용
● oAuth
● 매시업 어플리케이션을 위한 좀 더 강화된 인증방식
● 이 부분에 대해서는 뒤에서 더 자세하게 다룸
6. 보안 이슈
●
패스워드 저장
● 저장하지 말고 oAuth 를 쓰라고 강력히 권고
● Basic Authentication 은 곧 폐지 (deprecated) 될 것임
● SSL
●
트위터는 모든 REST API 에 SSL 을 지원
●
민감한 API 호출시 SSL 연결을 지원할 것을 권고
● 데스크탑 Apps
● 패스워드 저장시 암호화 서비스 사용 권고 (keyChain,
keyring)
7. 앞으로의 트위터 API
● Retweet API 의 지원
● statuses/home_timeline
● statuses/retweeted_by_me
● statuses/retweeted_to_me
● statuses/retweets_of_me
● statuses/retweet
● Streaming API
● 아직 알파테스트중
●
Geolocation API
9. oAuth 란 ?
● 매시업 어플리케이션이 다른 서비스의 API 를 호출
하기 위해서는 사용자의 권한을 가지고 있어야 함 .
● 이를 위해서 App Key 나 심지어 ID/PW 를 매시업
어플리케이션이 저장해야 하는 것이 문제
● 이를 해결하기 위한 새로운 인증 방식
● 공개 표준
● Google AuthSub, Yahoo! BBAuth 등과 비교
● 이들 서비스의 베스트 프랙티스를 모아 만들었
음
10. oAuth 를 발렛 키에 비유
● oAuth 는 당신이 사용하는 모든 웹서비스에
대한 발렛 키다 .
● 발렛 키는 당신의 차를 주차할 수 있을 정도의
권한만 제공하지 , 트렁크를 열거나 2 마일 이
상 운전하거나 RPM 의 빨간 선까지 속도를 내
는 권한은 없다 .
● 마찬가지로 , OAuth 키는 웹 에이전트가 당신
의 웹 메일을 체크하는 기능만 제공하며 , 당
신인 것처럼 해서 주소록에 있는 모든 사람에
게 메일을 보내는 일은 하지 못하게 한다 .
11. oAuth 인증에 관여하는 객체
● Service Provider(SP)
● 인증이 필요한 서비스를 제공하는 사이트
● User
● SP 에 인증을 할 수 있는 자격이 있는 사용자
● Consumer
● User 가 SP 의 데이터를 공유하길 원하는 사이
트 , Apps
● 사전에 SP 와 Consumer 는 신뢰 관계를 맺고
있어야 함
12. Oauth 인증에 관여하는 객체
● Protected Resources
● Consumer 가 인증을 통해 SP 로부터 제공받
고자 하는 데이터
● Tokens
● 비밀번호 (credentials) 대신 인증을 위한 키
● 임의의 문자열로 보통 구성되어 있음
14. oAuth 인증 프로세스
● Consumer 가 인증되지 않은 상태에서 SP 에
게 인증이 필요한 하는 자원을 요청
● SP 는 401 NotAuthorized 로 응답
● 응답시 헤더에 oAuth 인증이 필요함을 명시
WWW-Authenticate: Oauth realm="http://sp.example.com/"
● 이제 Consumer 는 oAuth 로 인증하기 위해
사전에 SP 로부터 받은 Consumer key 를 가
지고 요청
● SP 는 이 요청에 대해 Request Token 과
Request Secret 을 응답
15. oAuth 인증 프로세스
● Consumer 는 인증을 획득하기 위해 SP 의 인증
URL 로 사용자를 유도
● 이 때 request token 를 함께 보냄
● 또한 callback URL 을 보낼 수 있음
● 사용자는 SP 에 ID/PW 로 인증
● 인증 과정은 Consumer 는 전혀 관여하지 않음
● SP 는 request key 를 획득한 consumer 의 접근을
허락할 것인지를 사용자에게 물어보고 , 이를 승인
하면 해당 request key 를 승인 .
● callback URL 이 있다면 사용자를 유도
16. oAuth 인증 프로세스
● Consumer 는 이제 인증된 자원에 접근하기
위해 Request Token 을 Access Token 으로
바꾸어 줄 것을 요청함
● SP 는 요청을 분석하고 Access Token 및
Access Token Secret 을 응답함
● Access Token 을 받은 Consumer 는 이제 인
증된 자원에 접근할 수 있음
17. oAuth 인증시 보안
● 앞에 설명한 oAuth 인증 프로세스에서는 Token 및
secret 키의 무결성과 부인방지를 위한 방법이 생략
되었음
● 이를 위해 , 보안 연결 (HTTPS) 을 사용할 수 있음
● 하지만 HTTPS 는 설치 및 유지보수에 진입장벽이
높음
● 기본적으로 oAuth 는 비보안 연결을 위해 디자인되
었다고 언급하고 있음
● 비보안 연결을 위해 signing requests 를 할 것
을 명시하고 있음
18. oAuth 의 Signing request
● oAuth 는 Customer 의 모든 요청에
oauth_signature_method 파라미터를 명시한
signing request 를 사용할 것을 명시
● 보안 연결일 경우에는 signature_method 를
PLAINTEXT 로 사용 가능
● oAuth 스펙에서는 세 가지 signature_method
를 정의
● HMAC-SHA1, RSA-SHA1, PLAINTEXT
● Signing request 를 위해 요청시
oauth_signature 파라미터를 함께 보내도록
19. oAuth 의 Signing request
● oauth_signature
● Signature Base String 을 명시한
signature_mehtod 로 암호화 / 인코딩한 값
● Signature Base String
● signature_mehtod 가 PLAINTEXT 인 경우 ,
parameter_encode([consumer_secret]&[token_secret])
● 그 외 HMAC, RSA 를 사용할 경우
parameter_encode(hmac_or_rsa([all_parameters]))
23. Streaming Text Orientated
Messaging Protocol
● 스트리밍 메시지를 효과적으로 전송하기 위
한 프로토콜
● Client / Message Broker
● TCP 를 기반으로 동작함 (SSL 포함 )
● HTTP 와 유사한 방식 (coming from the HTTP
school of design), 매우 간단한 프로토콜
●
http://stomp.codehaus.org/ 에서 오픈소스
프로젝트로 진행중
● ActiveMQ 와 같은 잘 알려진 메시지 브로커에
서 지원
33. ERROR
ERROR
message: malformed packet received
The message:
-----
MESSAGE
destined:/queue/a
Hello queue a!
-----
Did not contain a destination header, which is required for message propagation.
^@