블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

REST API 디자인 가이드

아키텍쳐 /WEB 2.0 | 2014.06.12 21:54 | Posted by 조대협

REST API 디자인 가이드

조대협(http://bcho.tistory.com)

REST API 디자인을 보면, REST 사상에 맞춰서 제대로 디자인 (CRUD를 HTTP method에 맞춘)하기도 어렵고, URI Convention등이나 보안, 버전 관리등 고려할 사항이 많다. 이번 글에서는 REST API를 디자인에 대한 가이드를 소개하고자 한다.

동사보다는 명사를 사용하자

URL을 심플하고 직관적으로 만들자

REST API를 URL만 보고도, 직관적으로 이해할 수 있어야 한다
URL을 길게 만드는것 보다, 최대 2 depth 정도로 간단하게 만드는 것이 이해하기 편하다.

/dogs
/dogs/1234

URL에 동사보다는 명사를 사용한다.

REST API는 리소스에 대해서 행동을 정의하는 형태를 사용한다. 예를 들어서

POST /dogs

는 /dogs라는 리소스를 생성하라는 의미로, URL은 HTTP Method에 의해 CRUD (생성,읽기,수정,삭제)의 대상이 되는 개체(명사)라야 한다.
잘못된 예들을 보면

HTTP Post : /getDogs
HTTP Post : /setDogsOwner

위의 예제는 행위를 HTTP Post로 정의하지 않고, get/set 등의 행위를 URL에 붙인 경우인데, 좋지 않은 예 이다. 이보다는

HTTP Get : /dogs
HTTP Post : /dogs/{puppy}/owner/{terry}

를 사용하는 것이 좋다.
일반적으로 권고되는 디자인은 다음과 같다.

리소스POSTGETPUTDELETE
createreadupdatedelete
/dogs새로운 dogs 등록dogs 목록을 리턴Bulk로 여러 dogs 정보를 업데이트모든 dogs 정보를 삭제
/dogs/baduk에러baduk 이라는 이름의 dogs 정보를 리턴baduk이라는 이름의 dogs 정보를 업데이트baduk 이라는 이름의 dogs 정보를 삭제

단수(Singular) 보다는 복수(Plural)형 명상를 사용한다.

되도록이면 추상적인 이름보다 구체적인 이름을 사용하자

리소스간의 관계를 표현하는 방법

Option A.

다른 리소스와의 관계를 표현. 예를 들어 owner가 가지고 있는 개(dogs) 목록

GET /owner/{terry}/dogs

와 같이 /resource명/identifier/other-related-resource 형태로, 해당 리소스에 대한 경로를 /resource명/{그 리소스에 대한 identifier}/{연관되는 다른 리소스 other-related-resource} 형태로 표현한다.

Option B.

https://usergrid.incubator.apache.org/docs/relationships/ 에 보면 다른 형태의 관계 정의 방법에 대해서 나와 있는데, 조금 더 구체적인 API 관계 정의 방법은 다음과 같다.

/resource/identifier/relation/other-related-resource
GET /owner/terry/likes/dogs

이 방식은 리소스간의 관계(relationship)을 URL 내에 정의하는 방법으로,훨씬 더 명시적일 수 있다. (세련되어 보이지는 않지만)
리소스간의 관계가 복잡하지 않은 서비스의 경우에는 Option A를, 리소스간의 관계가 다소 복잡한 경우에는 Option B를 사용하도록 한다.

에러 처리

에러 처리의 기본은 HTTP Response Code를 사용한후, Response body에 error detail을 사용해주는 것이 좋다.

Use HTTP Status Code

HTTP Status Code는 대략 70개의 코드가 있다. 일반적인 개발자들이 모든 코드를 기억할리는 없고, 에러 코드에서는 자주 사용되는 몇개의 코드만 의미에 맞춰서 사용하는 것이 좋다.
Google의 GData의 경우에는 10개, Neflix의 경우에는 9개, Digg의 경우에는 8개를 사용한다.
(※ http://info.apigee.com/Portals/62317/docs/web%20api.pdf)

  • Google GData
    200 201 304 400 401 403 404 409 410 500
  • Netflix
    200 201 304 400 401 403 404 412 500
  • Digg
    200 400 401 403 404 410 500 503

필자의 경우, 아래와 같은 정도의 HTTP Code를 사용하기를 권장한다.

  • 200 성공
  • 400 Bad Request - field validation 실패시
  • 401 Unauthorized - API 인증,인가 실패
  • 404 Not found
  • 500 Internal Server Error - 서버 에러

자세한 HTTP Status Code는 http://en.wikipedia.org/wiki/Http_error_codes 를 참고하기 바란다.

Error Message

HTTP Status Code 이외에, Response body에 detail한 에러 정보를 표현하는 것이 좋은데,
Twillo의 Error Message 형식의 경우

HTTP Status Code : 401
{“status”:”401”,”message”:”Authenticate”,”code”:200003,”more info”:”http://www.twillo.com/docs/errors/20003"}

와 같이 표현하는데, 에러 코드 #와 해당 에러 코드 #에 대한 Error dictionary link를 제공한다.
비단 API 뿐 아니라, 잘 정의된 소프트웨어 제품의 경우에는 별도의 Error # 에 대한 Dictionary 를 제공하는데, Oracle의 WebLogic의 경우에도http://docs.oracle.com/cd/E24329_01/doc.1211/e26117/chapter_bea_messages.htm#sthref7 와 같이 Error #와, 이에 대한 자세한 설명과, 조치 방법등을 설명한다. 이는 개발자나 Trouble Shooting하는 사람에게 많은 정보를 제공해서, 조금 더 디버깅을 손쉽게 한다. (가급적이면 Error Code #를 제공하는 것이 좋다.)

Error Stack

에러메세지에서 Error Stack 정보를 출력하는 것은 대단히 위험한 일이다. 내부적인 코드 구조와 프레임웍 구조를 외부에 노출함으로써, 해커들에게, 해킹을 할 수 있는 정보를 제공하기 때문이다. 일반적인 서비스 구조에서는 아래와 같은 에러 스택정보를 API 에러 메세지에 포함 시키지 않는 것이 바람직 하다.

log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: stacktrace.log (Permission denied)
at java.io.FileOutputStream.openAppend(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:177)
at java.io.FileOutputStream.(FileOutputStream.java:102)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:290)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:164)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

그렇지만, 내부 개발중이거나 디버깅 시에는 매우 유용한데, API 서비스를 개발시, 서버의 모드를 production과 dev 모드로 분리해서, 옵션에 따라 dev 모드등으로 기동시, REST API의 에러 응답 메세지에 에러 스택 정보를 포함해서 리턴하도록 하면, 디버깅에 매우 유용하게 사용할 수 있다.

버전 관리

API 정의에서 중요한 것중의 하나는 버전 관리이다. 이미 배포된 API 의 경우에는 계속해서 서비스를 제공하면서,새로운 기능이 들어간 새로운 API를 배포할때는 하위 호환성을 보장하면서 서비스를 제공해야 하기 때문에, 같은 API라도 버전에 따라서 다른 기능을 제공하도록 하는 것이 필요하다.
API의 버전을 정의하는 방법에는 여러가지가 있는데,

  • Facebook ?v=2.0
  • salesforce.com /services/data/v20.0/sobjects/Account
    필자의 경우에는

    {servicename}/{version}/{REST URL}
    example) api.server.com/account/v2.0/groups

형태로 정의 하는 것을 권장한다.
이는 서비스의 배포 모델과 관계가 있는데, 자바 애플리케이션의 경우, account.v1.0.war, account.v2.0.war와 같이 다른 war로 각각 배포하여 버전별로 배포 바이너리를 관리할 수 있고, 앞단에 서비스 명을 별도의 URL로 떼어 놓는 것은 향후 서비스가 확장되었을 경우에, account 서비스만 별도의 서버로 분리해서 배포하는 경우를 생각할 수 있다.
외부로 제공되는 URL은 api.server.com/account/v2.0/groups로 하나의 서버를 가르키지만, 내부적으로, HAProxy등의 reverse proxy를 이용해서 이런 URL을 맵핑할 수 있는데, api.server.com/account/v2.0/groups를 내부적으로 account.server.com/v2.0/groups 로 맵핑 하도록 하면, 외부에 노출되는 URL 변경이 없이 향후 확장되었을때 서버를 물리적으로 분리해내기가 편리하다.

페이징 처리와 Partial response

페이징

큰 사이즈의 리스트 형태의 응답을 처리하기 위해서 필요한 것은 페이징 처리와 partial response 처리이다. 리스트 내용이 1000,000개인데, 이를 하나의 HTTP Response로 처리하는 것은 서버 성능, 네트워크 비용도 문제지만 무엇보다 비현실적이다. 그래서, 페이징을 고려하는 것이 중요하다.
페이징을 처리하기 위해서는 여러가지 디자인이 있다.

예를 들어 100번째 레코드부터 125번째 레코드까지 받는 API를 정의하면

  • Facebook API 스타일 : /record?offset=100&limit=25
  • Twitter API 스타일 : /record?page=5&rpp=25 (RPP는 Record per page로 페이지당 레코드수로 RPP=25이면 페이지 5는 100~125 레코드가 된다.)
  • LikedIn API 스타일 : /record?start=50&count=25

apigee의 API가이드를 보면 좀더 직관적이라는 이유로 페이스북 스타일을 권장하고 있다.
record?offset=100&limit=25

Partial Response (Optional)

리소스에 대한 응답 메세지에 대해서 굳이 모든 필드를 포함할 필요가 없는 케이스가 있다. 예를 들어 페이스북 FEED의 경우에는 사용자 ID, 이름, 글 내용, 날짜, 좋아요 카운트, 댓글, 사용자 사진등등 여러가지 정보를 갖는데, API를 요청하는 Client의 용도에 따라 선별적으로 몇가지 필드만이 필요한 경우가 있다. 필드를 제한하는 것은 전체 응답의 양을 줄여서 네트워크 대역폭(특히 모바일에서) 절약할 수 있고, 응답 메세지를 간소화하여 파싱등을 간략화할 수 있다.
그래서 몇몇 잘 디자인된, REST API의 경우 이러한 Partial Response 기능을 제공하는데, 주요 서비스들을 비교해보면 다음과 같다.

  • Linked in : /people:(id,first-name,last-name,industry)
  • Facebook : /terry/friends?fields=id,name
  • Google : ?fields=title,media:group(media:thumnail)
    Linked in 스타일의 경우 가독성은 높지만 :()로 구별하기 때문에, HTTP 프레임웍으로 파싱하기가 어렵다. 전체를 하나의 URL로 인식하고, :( 부분을 별도의 Parameter로 구별하지 않기 때문이다.
    Facebook과 Google은 비슷한 접근 방법을 사용하는데, 특히 Google의 스타일은 더 재미있는데, group(media:thumnail) 와 같이 JSON의 Sub-Object 개념을 지원한다.
    Partial Response는 Google 스타일을 이용하는 것을 권장한다.

검색

검색은 일반적으로 HTTP GET에서 Query String에 검색 조건을 정의하는 경우가 일반적인데, 이 경우 검색조건이 다른 Query String과 섞여 버릴 수 있다. 예를 들어 name=cho이고, region=seoul인 사용자를 검색하는 검색을 Query String만 사용하게 되면 다음과 같이 표현할 수 있다.
/users?name=cho&region=seoul
그런데, 여기에 페이징 처리를 추가하게 되면

/users?name=cho&region=seoul&offset=20&limit=10

페이징 처리에 정의된 offset과 limit가 검색 조건인지 아니면 페이징 조건인지 분간이 안간다. 그래서, 쿼리 조건은 하나의 Query String으로 정의하는 것이 좋은데

/user?q=name%3Dcho,region%3Dseoul&offset=20&limit=10

이런식으로 검색 조건을 URLEncode를 써서 “q=name%3Dcho,region%3D=seoul” 처럼 (실제로는 q= name=cho,region=seoul )표현하고 Deleminator를 , 등을 사용하게 되면 검색 조건은 다른 Query 스트링과 분리된다.
물론 이 검색 조건은 서버에 의해서 토큰 단위로 파싱되어야 하낟.

전역 검색과 리소스 검색

다음으로는 검색의 범위에 대해서 고려할 필요가 있는데, 전역 검색은 전체 리소스에 대한 검색을, 리소스에 대한 검색은 특정 리소스에 대한 검색을 정의한다.
예를 들어 시스템에 user,dogs,cars와 같은 리소스가 정의되어 있을때,id=’terry’인 리소스에 대한 전역 검색은

/search?q=id%3Dterry

와 같은 식으로 정의할 수 있다. /search와 같은 전역 검색 URI를 사용하는 것이다.
반대로 특정 리소스안에서만의 검색은

/users?q=id%3Dterry

와 같이 리소스명에 쿼리 조건을 붙이는 식으로 표현이 가능하다.

HATEOAS (Optional)

HATEOS는 Hypermedia as the engine of application state의 약어로, 디자인의 요지는 하이퍼미디어의 특징을 이용하여 HTTP Response에 다음 Action에 대한 HTTP Link를 함께 리턴하는 것이다.
예를 들어 앞서 설명한 페이징 처리의 경우, 리턴시, 전후페이지에 대한 링크를 제공한다거나

HTTP GET users?offset=10&limit=5
{
[
{‘id’:’user1’,’name’:’terry’}
,{‘id’:’user2’,’name’:’carry’}
]
,’links’ :[
{
‘rel’:’pre_page’,
‘href’:’http://xxx/users?offset=6&limit=5
}
,
{
‘rel’:’next_page’,
‘href’:’http://xxx/users?offset=11&limit=5
}
]
}
와 같이 표현하거나
연관된 리소스에 대한 디테일한 링크를 표시 하는 것등에 이용할 수 있다.
HTTP GET users/terry
{
‘id’:’terry’
‘links’:[{
‘rel’:’friends’,
‘href’:’http://xxx/users/terry/friends
}]
}

HATEOAS를 API에 적용하게 되면, Self-Descriptive 특성이 증대되어 API에 대한 가독성이 증가하는 장점을 가지고 있기는 하지만, 응답 메세지가 다른 리소스 URI에 대한 의존성을 가지기 때문에, 구현이 다소 까다롭다는 단점이 있다.
요즘은 Spring과 같은 프레임웍에서 프레임웍 차원에서 HATEOAS를 지원하고 있으니 참고하기 바란다.http://spring.io/understanding/HATEOAS

단일 API URL

API 서버가 물리적으로 분리된 여러개의 서버에서 동작하고 있을때, user.apiserver.com, car.apiserver.com과 같이 API 서비스마다 URL이 분리되어 있으면 개발자가 사용하기 불편하다. 매번 다른 서버로 연결을 해야하거니와 중간에 방화벽이라도 있으면, 일일이 방화벽을 해제해야 한다.
API 서비스는 물리적으로 서버가 분리되어 있더라도 단일 URL을 사용하는 것이 좋은데, 방법은 HAProxy나 nginx와 같은 reverse proxy를 사용하는 방법이 있다.
HAProxy를 앞에 새우고 api.apiserver.com이라는 단일 URL을 구축한후에
HAProxy 설정에서

api.apiserver.com/user는 user.apiserver.com 로 라우팅하게 하고
api.apiserver.com/car 는 car.apiserver.com으로 라우팅 하도록 구현하면 된다.

보안

API 서비스에 있어서 보안은 매우 중요한 요소이다. API 에 대한 보안은 다음과 같이 보안 대상에 따라서 몇가지로 나눠진다.

인증

인증은, API를 호출하는 클라이언트가 VALID한 사용자인지, 불법적인 사용자인지를 구별하는 방식이다.

HTTP Basic Auth

가장 쉬운 방식으로는 사용자 id,password를 표준 HTTP Basic Auth에 넣어서 전송하는 방식으로 사용자 단위의 인증과 권한 컨트롤이 가능하다는 장점을 가지고 있다. 그러나 이 경우, 매번 사용자 id와 password가 네트워크를 통해서 전송되기 때문에, 해커에 의해서 사용자 id,password가 누출될 수 있다. 사용자 id,password가 누출되면 API 호출 권한뿐만 아니라 웹에 로그인해서 다른 서비스를 사용하는 등 치명적이기 때문에 그리 권장되지 않는 방법이다.
SSL을 사용해서 암호화할 수 는 있겠지만 기본적으로 SSL은 Man in the middle attack (중간에 인증서를 가로체서 SSL 패킷을 열어보는 방법) 에 취약하기 때문에 완벽하다고 볼 수 없다.

Access Token

매번 네트워크를 통해서 사용자 id,password를 보내는 것이 위험하다면, 처음 인증시에만 id,password를 보내고, 인증이 성공하면 서버에서 access_token을 발급하여 API 호출시 access_token으로만 호출하는 방식이다. (OAuth2.0이 유사한 메커니즘을 사용한다.) 이 경우 API를 호출하는 클라이언트가 access_token을 저장하는 메카니즘을 가져야 한다. 또한 access_token이 누출될때를 대비하여, 서버쪽에서 compromised된 (노출된/오염된) token의 경우 revoke(사용금지 처리)를 하고, 클라이언트에게 다시 access_token을 발급하도록 하는 메커니즘과, Expire time을 둬서 주기적으로 token을 교체하도록 하는 방식이 좋다.

API Key

API Key 시나리오는 일반적으로 API 제공자가 API 포탈등을 통해서, 개발자를 인증하고 개발자에게 API Key를 발급한후, 개발자가 API Key를 애플리케이션 코드내에 탑재해서 사용하는 방법을 사용한다. API를 외부 파트너에게 공개하는 경우에 손쉽게 사용할 수 있으며, 꽤 많이 사용되던 방식이다. 단 애플리케이션 (특히 모바일 애플리케이션)이 디컴파일 될 경우 API Key가 누출될 수 있는 위험성을 가지고 있기 때문에, API Key를 잘 관리 하는 것이 중요하다. (난독화를 한다던가)
이 시나리오의 경우 애플리케이션 단위의 인증을 하기 때문에 앞서 설명한 두 방식처럼 사용자 단위의 인증은 불가능 하다.
(사용자 단위의 인증이 필요한 경우 API Key로 애플리케이션을 인증한 후에, 클라이언트 마다 새로운 access_token을 발급하는 방식을 사용할 수 있다. 사실 이게 OAuth 2.0의 client_secret과 access_token 시나리오와 유사하다.)

OAuth 2.0 (Recommended)

OAuth는 근래에 가장 많이 사용되는 API 인가/인증 기술이다. 특징중의 하나는 Authentication(인증)만이 아니라 권한에 대한 통제(Authorization)이 가능하다는 특징을 가지고 있으며, 3 legged 인증을 통해서, 파트너사가 API를 사용할 경우, 인증시에 사용자 ID와 비밀번호를 파트너에게 노출하지 않을 수 있는 장점이 있다. (페이스북 계정을 이용한 웹 애플리케이션들을 보면 가끔, 페이스북 로그인 화면으로 리다이렉트되어 “XX 애플리케이션이 XX에 대한 권한을 요청합니다. 수락하시겠습니까?”와 같은 창이 뜨는 것을 볼 수 있는데, 페이스북 로그인 화면에, 사용자 ID와 비밀 번호를 넣고 페이스북은 인증이 되었다는 정보를 인증을 요청한 웹애플리케이션으로 보내서, 해당 사용자가 인증되었음을 알려준다. 이경우, 웹 애플리케이션은 사용자의 비밀번호를 알 수 없다. )
기본적인 OAuth의 원리는, 사용자 ID/PASSWD로 인증을 한 후에, access_token을 받아서, access_token을 이용해서 추후 커뮤니케이션을 하는 방식이다.

OAuth는 크게 용도에 따라 4가지 타입의 인증 방식을 제공한다.

  • Authorization Code 방식 - 주로 웹 애플리케이션 인증에 유리하며, 위에서 설명한 케이스와 같이 웹을 통해서 Redirect 하는 방식이다.
  • Implicit 방식 - 자바스크립트 기반의 애플리케이션이나 모바일 애플리케이션 처럼 서버 백엔드가 없는 경우 사용한다.
  • Resource Owner password credential 방식 - 인증을 요청하는 클라이언트에서 직접 ID와 PASSWD를 보내는 방식으로, (이 경우 위의 방식들과 다르게 서비스 제공자의 로그인창으로 리다이렉션이 필요 없다.) 클라이언트가 직접 ID,PASSWD를 받기 때문에, 클라이언트에 사용자의 비밀번호가 노출될 수 있어서 서버와 클라이언트를 같은 회사에서 제작한 경우나, 사용자의 정보를 공유해도 되는 1’st party 파트너등과 같은 경우에 사용한다.
  • Client Credential 방식 - 일반적인 애플리케이션 Access에 사용한다.

일반적으로 API를 3’rd party에 제공할 경우에는 Authorization Code 방식을, 자사의 API를 자사나 1’st party 파트너만 사용할 경우에는 Resource Owner password credential 방식이 좋다.

Mutual SSL

가장 강력한 인증 방법으로,클라이언트와 서버가 각자 인증서를 가지고 상호 인증하는 방식이다. 양방향(2-way)SSL 이라고도 한다. 이 경우에는 클라이언트의 인증서(Certificate)를 서버에게 안전하게 전송할 수 있는 메커니즘이 필요하다. 클라이언트가 접속했을때, Certificate를 네트워크를 통해서 전송하고, 서버는 이 인증서가 공인된 인증서인지를 확인하는 방법도 있고, 내지는 서버의 Admin Console등을 통해서 클라이언트가 사용하는 인증서 자체를 업로드 해놓는 방법등 다양한 방법이 있다.
Mutual SSL은 양쪽에 인증서를 사용하기 때문에, Man in the middle attack이 불가능하고, Packet을 snipping해서 보는 것 조차도 불가능 하다. (대신 구현이 다소 까다롭다.)

WhiteList 방식

서버간의 통신에서는 가장 간단하게 할 수 있는 방식이 서버가 API 호출을 허용할 수 있는 IP 목록을 유지하는 방법이다. (WhiteList 방식). 다른 IP에서 들어오는 API 호출의 경우 받지 않는 방법으로, 가장 구현이 간단하다. 방화벽이나 Reverse proxy 설정등으로도 가능하고, 필요하다면, VPN (Virtual Private Network)등을 이용할 수 도 있다.

프로토콜 레벨 암호화

HTTP 통신 프로토콜 자체를 암호화 하는 방식인데, SSL을 이용한 HTTPS가 대표적인 경우이다. API 디자인에서 HTTPS는 반드시 적용하는 것을 권장한다.
HTTPS는 앞에서도 잠깐 언급했듯이 Man in the middle attack에 취약한데 Man in the middle attack의 기본적인 메커니즘은 서버에서 보낸 인증서를 바꿔치기 해서, 클라이언트로 보내는 방식을 이용한다. (http://en.wikipedia.org/wiki/Man-in-the-middle_attack)
가능하면, 인증서 체크 로직을 클라이언트에 두는 것이 좋다. 인증서가 공인된 인증서인지, (또는 그 서버의 인증서가 맞는지를 Issuer등을 통해서 확인할 수 있다. 인증서에 있는 내용들은 기본적으로 중간에 해커가 바꿀 수 다 없다. Signing이 되어있기 때문에, 내용을 바꾸면 Singing된 Signature가 맞지 않는다.) attack

메세지 레벨 암호화

다음으로 JSON과 같은 메세지 자체를 암호화할 수 있는데, 앞서 설명해듯이 SSL을 사용하더라도, 중간에 인증서를 바꿔 치는 등의 행위를 통해서 패킷을 열어볼 경우, 메세지 내용을 노출될 가능성이 있기 때문에 이를 방지 하기 위해서, 중요한 메세지는 암호화하는 것을 권장한다.
이때 전체 메세지를 암호화 하는 것은 비효율적이며 특정 필드의 값만 필요에 따라서 암호화를 하는 것이 좋다.

무결성 관리 (HMAC)

메세지의 무결성 보장이란, 중간에 해커에 의해서 메세지가 변경할 수 없도록 하는 것이다. 기본적인 원리는 메세지에 대한 해쉬값을 계산해서, 보내서, 받는 쪽에서 받은 메세지를 가지고 똑같은 알고리즘으로 해쉬를 생성한후, 보내온 해쉬값과 비교하는 방법을 사용한다. 만약에 메세지가 변조가 되었다면,해쉬값이 일치하지 않기 때문에 메세지 변조 여부를 파악할 수 있다. 자세한 설명과 구현 방법은 http://bcho.tistory.com/807를 참고하기 바란다.

지금까지 간략하게 나마 REST API 설계 방식에 대해서 알아보았다.
자세한 자료들은 아래 참고 자료들은 참고하기 바란다.

참고 : http://info.apigee.com/Portals/62317/docs/web%20api.pdf
참고 : APICract Google groups https://groups.google.com/forum/?fromgroups#!topic/api-craft/
참고 : 마틴파울러의 ‘Glory of REST 향한 단계들’ http://jinson.tistory.com/190


새로운 문서가 업데이트 되었습니다.

REST API 이해와 설계 - #1 개념 잡기 http://bcho.tistory.com/953

REST API 이해와 설계 - #2 디자인 가이드  http://bcho.tistory.com/954

REST API 이해와 설계 - #3 보안 가이드  http://bcho.tistory.com/955



저작자 표시
신고

HTML 5의 큰 변화점

아키텍쳐 /WEB 2.0 | 2012.07.11 22:34 | Posted by 조대협

기존 단순 UI 플랫폼에서 발전하여

  • Storage 지원으로 인하여, 네트워크 연결이 없이도, 어느정도의 기능을 하는 애플리케이션 제작이 가능함. (Key Value 기반의 localStorage, RDB 성격의 clientDB)
  • WebSocket을 통하여, AJAX등을 이용한 long polling에서 바로 서버와 클라이언트간 메세지를 받을 수 있기 때문에 더 빠른 응답시간과 사용자 경험을 제공할 수 있는 UI가 가능하다. (아직 완성되지는 않았음)
  • 별도의 플러그인 없이 Video와 Audio를 사용할 수 있다.


단순 링크된 문서 뷰어에서 단독 저장공간과 서버로의 역방향 연결성 제공 멀티미디어 기능 강화를 통해서 리치 클라이언트 플랫폼으로 업그레이됨


저작자 표시
신고

ROA (REST 아키텍쳐)의 완성

아키텍쳐 /WEB 2.0 | 2010.03.22 17:23 | Posted by 조대협

고객사 차세대 아키텍쳐에 대한 Blue Print를 Research하다가 NoSQL (Cassandra, HBase)등을 reference했는데, 결과적으로 ROA 아키텍쳐의 완성은 NoSQL DBMS가 있어야 하는게 아닌가 싶다.

보고용 Article을 좀 쓰다가 정리가 안되서 blog에 포스팅하는데,
ROA에서 문제는 기존의 RDBMS는 ROA의 Resource구조와 맵핑이 잘 안된다.
ROA는 1 resource가 하나의 저장소에 저장되는 형태가 좋은데, (하나의 ROW라던지). RDBMS는 여러개의 Table에 걸쳐서 데이타가 나누어 저장되고, Key 구조도 FK를 이용하거나해서 복합 키가 생겨 버려서 Key 정의에도 모호성이 보인다.

반면에 NoSQL DB, 특히 Column형 DB는 Key & Value형태를 가지고 Value는 Schmeless로 아무 데이타형이나 들어갈 수 있기 때문에, (마치 HashTable에 VO를 Object 형으로 넣으면 모든 데이타 타입을 다 넣을 수 있는것 처럼) ROA 에 딱 맞아 떨어진다. 그것도 아주!! 기가막히게...

벌써 Facebook,Digg,Twitter들도 MySQL에서 Cassandra로 많이 전환하였다.
성능과 안정성 대용량 데이타 모두 지원하니 최고이기는 한데,
문제는 이런 SNS 애플리케이션들은 데이타 구조가 엔터프라이즈 애플리케이션에 비해서 많이 간단하다는 것이다. Reference관계가 없더라도 구현이 가능하다는 것이다.

반면 엔터프라이즈 애프리케이션은 각 엔터티간 관계 복잡한 관계 설정이 필요하다.

내린 결론은 ROA의 가장 이상적인 아키텍쳐는(본인 생각에)
ESB를 통한 유연성을 제공해주는 진입부분, REST 컴포넌트 그리고 NoSQL DBMS이다.
단 복잡도가 높은 엔터프라이즈 애플리케이션에는 적용하기가 어렵고 복잡도가 상대적으로 낮은 SNS성에 적합하다

결국 엔터프라이즈는 SOAP을 경량화해서 구현하는게 정답이 아닐까 싶다.

저작자 표시
신고

트위터를 사용하면서.

아키텍쳐 /WEB 2.0 | 2009.11.11 22:54 | Posted by 조대협
트위터를 사용한지가 대략 한달이 좀 넘어가는것 같습니다.
사실 고객이 엔터프라이즈 마이크로 블로그 (기업용 트위터)를 사용하겠다는 요구가 있어서 리서치 하다보니까는 어찌어찌하다가 여기까지 왔네요.
오늘 600번째 트윗을 올리고, 현재 Follower가 95명입니다. 곧 100명 채우겠네요.

요즘 대부분의 정보는 트윗터를 통해서 얻습니다. 140자밖에 안되기 때문에 읽기도 부담없고 왠만해서는 클릭도 필요없습니다. 그리고 소위 말하는 입소문이기 때문에 정보 전파력도 빠릅니다. 많이 펌질 (RT되는) 트윗은 또 그만큼 정보 가치가 높은것을 의미하기 때문에, 정보에 대한 필터링 능력도 좋구요. 

오히려 메타블로그나 포탈 또는 전문 사이트 보다 최신 정보나 트렌드 파악하기에는 더욱더 좋은것 같습니다.

아.. 제 트윗아이디는 TerryCho입니다. 요즘 안드로이드와 구글의 세계정복 음모 소식에 대해서 가끔 트윗하고 있습니다. 서로 많은 정보 공유했으면 좋겠습니다. :)

저작자 표시
신고
TAG 트위터

Google wave

아키텍쳐 /WEB 2.0 | 2009.11.11 22:27 | Posted by 조대협

오늘 뜻하지 않게 Fenton으로 부터 Google wave에 invitation을 받아서 사용해보았습니다.
Google wave에 대해서 '이게 모하는 툴이냐?' 라는 질문을 가끔 받는데, 
제 생각을 정리해서 이야기 해보면, 일종의 협업을 지원하는 웹OS또는 플랫폼입니다.
간단하게는 멀티미디어 채팅 (채팅중에, 맵이나 각종 가젯을 추가해서 문서를 만들 수 있고. )과 비슷합니다. 여러 사람이 공동작업으로 하나의 문서를 만들 수 있으며, 문서를 만들면서의 과정이 레코딩되서 리플레이가 가능합니다. 이건 기본적인 기능이고
 gw(google wave,이하 gw)는 Extension을 추가함으로써 협업이 가능하게 한다는 것입니다.

예를 들어 issue tracking system의 extension이 추가되었다고 생각해봅시다. (Atlassian의 JIRA와 같은) JIRA내에서는 코어 시스템 개발자와, 기술 지원 엔지니어가 하나의 이슈를 풀기 위해서 Issue를 오픈했을때 둘간의 communication은 text와 첨부 파일만으로 이루어지고 이 과정역시 async식으로 이루어집니다. 별도의 실시간 커뮤니케이션이 필요할 경우 전화나 메신져를 이용하게 되지만, 이 경우에는 대화내용을 별도로 정리하여 기록한후에 issue에 comment로 attach해야 합니다.

만약 여기에 gw가 추가 된다면?
이슈에 대해서 wave를 오픈하고, 채팅과 같은 방법으로 문서 내용을 추가합니다. '로그가 어쩌고 저쩌고... 현재 증상이 어쩌고...'  코어 개발자가 장애 시스템의 콘솔을 보고자 합니다. 그러면 Virtual desktop의 extension을 이용하여 기술 지원 엔지니어의 PC화면을 열어주고, 코어개발자가 이것저것 테스트합니다. 그 다음 내용을 같이 정리해 나가겠지요. 코어 개발자가 문제를 풀지 못해서, 시니어 개발자를 해당 wave로 초대합니다. 시니어 개발자는 wave 내용을 replay해서 두 사람이 대화한 내용과, 과정 그리고 virtual desktop에서 코어 개발자가 한 행위를 비디오 보듯이 봅니다. 더 이상 물어볼 필요가 없다는 것이지요. 그 자리에 있었던 것처럼 모든 행위가 리플레이가 되니까요.
여기서 커뮤니케이션에서 가장 중요한 히스토리를 이해하고 context(현재 상황)을 이해하는데, 기존의 커뮤니케이션 방법에 비해서 비용이 들지 않는 것이 보이고, 기존의 커뮤니케이션 방식과 다르게, 실시간이나 비동기 방식 모두를 지원하며, 화상,텍스트,보이스와 같이 한정된 수단이 아닌 Extension을 통한 다양한 소통이 가능하게 됩니다.

또 다른 시나리오를 들어볼까요? 비지니스 프로세스를 모델링한다고 합니다.
현업 A씨와 프로세스 전문가 B씨가 프로세스를 모델링하기 위해서 웨이브를 오픈합니다.B씨는 Extension의 BPA (모델링 도구)를 이용해서 프로세스를 그려나가기 시작합니다. A씨는 화상통화나, 채팅으로 의견을 개진하면서, 모델이 실무 내용과 가깝도록 수정해가면서 작업을 합니다.A씨가 퇴근을 합니다. 교대한 C씨가 업무를 이어 받습니다. C씨는 wave를 replay해서 두사람이 어떤 작업을 했는지 봅니다. (BPA에서 그림을 그렸다 지우거나 수정한 부분까지 비디오 보듯이 replay가 되겠지요.) C씨는 같은 방법으로 B씨와 협업을 합니다.

대충 생각할 수 있는 시나리오는 위와 같습니다.
기존의 소통 도구와 차이점은 위에서 설명했듯이 여러 가지 수단의 소통 도구를 사용할 수 있고, 실시간과 비동기 소통이 가능하며 무엇보다 커뮤니케이션 내용을 내용이 아닌 행위로 기록하고 저장할 수 있다는 겁니다. (Archiving이 되서 추후에 저장 분리 및 검색이 가능합니다.) 성공 실패의 가장 중요한 요인은 얼마나 많은 Extension을 제공할것이며, Extension 개발을 위한 환경을 얼마나 잘 제공하느냐 일겁니다.

일반적인 협업보다는 그룹웨어와 같이 기업이나 특정 목적을 지닌 집단에게 매우 유리할거같습니다. 제가 보기에는 모눈에는 모만 보인다고 기업용 플랫폼 같습니다. 

구글 Apps가 기업에 플랫폼으로 도입되고 있고, GMAIL이 기업의 표준 메일 시스템으로 자리잡아가고 있는 지금 wave까지 나오니 구글이 더이상 일반 서비스 기업이 아니라 전통적인 엔터프라이즈 시장에도 슬금슬금 파고 들어오는 느낌입니다.

안드로이드도 그렇고, 웨이브도 그렇고..구글의 언어인 GO, 구글 App 서버 등등 구글의 지구 정복 음모가 (?) 점점 구체화 되어가는것 같습니다. (근래에 가장 혁신적인 회사지요. 모든 분야를 마음데로 넘나들고 있습니다.) 구글 같은 회사에서 일하고 싶네요. :)

저작자 표시
신고

기업에서 마이크로 블로그의 도입

지금까지 마이크로 블로그에 대해서 알아보았다. 그러면 이 마이크로 블로그 시스템을 기업에 어떻게 적용할 수 있을까

기업 내부 협업 플랫폼으로써의 마이크로 블로그

먼저 기업 내부의 협업 플랫폼으로써 마이크로 블로그를 도입한다면 어떤 기대 효과를 얻을 수 있을지 살펴본다

개인 브랜드 개발

트윗 메시지의 포스팅의 질은 개인의 브랜드와 직결된다. 전문성이 많은 포스트나 현재의 일 진행 상황을 자세하게 기록하면서 개인의 브랜드 가치를 향상 시킬 수 있으며, 특정화된 브랜드는 조직입장에서 업무의 효율성이 높은 직원을 선별해내고, 조직내에서 전문성을 가지고 있는 사람을 쉽게 찾을 수 있게 한다

리스크 조기 감지

마이크로 블로그 내의 RT Hash Tag를 분석함으로써 현재 회사내의 트렌드를 감지할 수 있으며, 이를 통해서 특정 Risk 요인이 있을 경우에 조기에 발견할 수 있는 일종의 사내 조기 경보기와 같은 역할이 가능하다

전문가와 네트워크 구축

실제로 기업의 규모가 커지면 커질수록 많은 비즈니스 부서가 존재하고, 협업이 필요할 때 누가 전문성을 가지고 있는지를 알아내기가 매우 어렵다. 이는 조직의 결재 구조를 따라서 인재를 요청하거나 또는 인맥을 통하여 추천을 받는 방식을 사용하는데,검증이 쉽지 않고 시간이 많이 걸리는 문제가 있다. 마이크로 블로그의 검색을 통해서 특정 분야에 관심이 있는 사람을 검색하고 그 사람의 트윗 메시지를 살펴봄으로써 필요한 전문성이 있는 사람을 쉽게 찾을 수 있고 네트워크를 구축하여 업무적으로 필요한 전문지식에 대해서 도움을 받을 수 있다

지식 공유

마이크로 블로그내에 링크로 저장되어 있는 많은 문서와 전문성을 가진 사람들이 추천하는 링크 그리고 RT된 링크들은 링크된 문서의 신뢰도를 나타내어 주며 기존의 검색엔진(구글과 같은)과 다른 형태의 지식 검색 및 공유 방법을 제공한다. 단순하게 텍스트나 내용의 일치가 아니라 Following하고 있는 사람의 신뢰도와, 많은 사람에 의해서 퍼 날라지거나 인용된 문서의 경우 신뢰도가 높다는 사람의 신뢰 중심의 지식 검색이 가능하게 된다

업무에 대한 컨텍스트 공유

프로젝트나 업무 그룹에 대해서 그룹 필터를 사용하여 진척 상황이나 이슈를 포스팅하여 구성원과 이해 당사자들이 해당 업무에 대한 진행현황(Context)에 대해서 이해할 수 있도록 한다. 현황과 상황은 과거에서부터 현재 어떻게 되고 있다는 Context를 나타내는 만큼, 당사자가 한두번의 브리핑이나 이메일로 현재 업무의 진행 상태를 파악하기가 어렵다. 마이크로 블로그를 통해서 업무에 대해서 계속해서 포스팅을 하면 포스팅 내용이 시간의 순서대로 연결이 되어 업무에 대한 Context의 의미를 가지게 된다

신뢰감 증대 및 관계 개선

마이크로 블로그를 통해서 임원과 같이 조직에서 일반적으로 접하기 쉽지 않은 사람을 Following 하는 행위 자체만으로도 심리적인 유대감을 형성할 수 있다. 거기에 더해서 해당 임원에게 보낸 답변에 대해서 응답이라도 받는 경우에는 구체적인 교감이 있는 것으로 인식이 되서 심리적으로 느끼는 거리가 줄어든다.

또한 마이크로 블로그의 트윗 포스트는 메일이나 게시판과 같이 정형화된 커뮤니케이션이 아니라 좀더 캐주얼하고 비업무적인 부분 (그날의 기분, 일상)도 다루기 때문에 업무적이 아니라 인간적인면 즉 감성적인 커뮤니케이션을 통해서 직원간의 거리를 줄일 수 있게 한다.

결과적으로 좀더 활발한 커뮤니케이션을 유도하여 조직의 구조에서 오는 커뮤니케이션의 장벽을 허물 수 있고 구성원간의 신뢰도를 높일 수 있다

수평적이고 오픈된 커뮤니케이션

기업의 커뮤니케이션 문화는 수직 계층적인 문화를 가지고 있다. 여러 계층을 통하다 보니 커뮤니케이션의 효율성은 떨어지고, 좋은 아이디어나 의견이 하층에서 상층까지 제대로 전달되지 않거나 경영조직의 메시지가 스팸으로 취급되어 버리는 경우가 많다. 마이크로 블로그에서는 조직간의 상하 관계가 없으며 이슈와 주제만으로 커뮤니케이션을 하기 때문에 수직 계층에서 오는 이러한 차이를 극복할 수 있게 하고, 조직의 구조화된 커뮤니케이션 구조를 수평/네트워크화된 형태의 커뮤니케이션 구조로 개선할 수 있다

Near Real Time형태의 커뮤니케이션 스타일

이메일과 게시판, 메모 시스템들을 대체하여 간단한 비동기적인 커뮤니케이션을 효율적으로 수행할 수 있으며 특히 모바일 디바이스 연동을 통해서 장소와 시간에 관계 없는 커뮤니케이션 플랫폼을 구축할 수 있다. 

기업 외부로의 마이크로 블로그

기업이 비즈니스를 하는데 외부 관점으로는 어떻게 마이크로 블로그를 사용할 수 있을까? 주로 대고객 서비스에 마이크로 블로그를 적용할 수 있고, 실제로 S전자,L전자와 같은 글로벌 국내 기업이나 아마존 같은 기업들은 이미 트위터를 통해서 마케팅 활동을 진행하고 있다.

마케팅

새로운 제품에 대한 정보 제공이나 이벤트 행사등에 사용할 수 있다.

고객 서비스

고객의 불만 접수, 고객 모니터링등에 이용 가능하다

본 글을 기업내의 마이크로 블로그 구축 전략을 중점으로 다루고 있기 때문에 기업 외부에 있는 마이크로 블로그를 이용하여 기업 활동을 증진 시키는 방안에 대해서는 자세하게 설명하지는 않는다.

 기업에서 마이크로 블로그 아키텍쳐


Figure 2 Micro blog architecture for enterprise

 사용자 인터페이스

마이크로 블로그는 직원에게 다양한 사용자 인터페이스를 제공하며 기업의 기존 시스템들과 통한된다.

(1)    웹 인터페이스

가장 일반적인 형태의 인터페이스로, 마이크로 블로그 시스템의 고유 웹인터페이스이다.

(2)    모바일 디바이스

이동이 가능한 핸드폰이나 PDA같은 모바일 디바이스로 마이크로 블로그를 서비스 한다. 단말의 종류 서비스 국가에 따라서 서비스 형태가 다르게 제공된다. 스마트 폰의 경우 애플리케이션 형태로 2G이하의 폰의 경우 SMS형태로 서비스가 제공된다.

(3)    포탈

기업의 엔터프라이즈 포탈이 있을 경우, 포탈을 통해서 마이크로 블로그 서비스를 포틀릿 형태로 서비스 한다.

(4)    IM (Instant Messenger)

기업내 메신져와 통합하여 메신져를 통해서 트윗 메시지를 포스팅하거나 반대로 메신져를 통해서 Following하는 대상의 메시지를 받을 수 있게 한다.

(5)    기타 엔터프라이즈 애플리케이션

엔터프라이즈 시스템의 Notification. 예를 들어 Work flow Approval Request등이 기존 이메일 시스템들을 마이크로 블로그로 대체할 수 있다

IDM (Identity Management System)

기업내부에 이미 사용중인 직원 정보 (LDAP 등에 적용된 조직도나 직원 프로필 서비스)시스템인IDM Single Sign On등을 통해서 계정이 통합되어야 한다.

모바일게이트웨이

모바일 디바이스를 지원하기 위해서 통신사의 통신망을 이용하기 위한 게이트웨이이다.

모바일 디바이스의 타입과 연동 방식에 따라 텍스트 기반인 경우 SMS를 멀티미디어 기반의 경우 MMS를 지원하고 스마트폰 기반의 애플리케이션의 경우 TCP/IP 망등을 지원해야 한다.

즉 모바일 디바이스에 따라 모바일 게이트웨이의 연동 방식이 변경될 수 있다.

또한 글로벌 기업의 경우 각 나라마다 텔레콤 회사가 다르기 때문에 사용자의 근무 위치에 따라서 다른 모바일 게이트웨이를 사용하도록 한다.

검색엔진 및 소셜분석 도구

앞서 기업 내부 플랫폼의로써의 마이크로 블로그에서도 언급했듯이 마이크로 블로그의 포스팅 내용은 정보성을 갖는다. 특히 기존의 정확도 기준의 검색 방식이 아니라 마이크로 블로그에 의해서 언급된 비율이나 내가 Following하고 있는 사람이 언급한 정보(같은 이슈를 공유할 가능성이 높기 때문에)는 검색의 정확성이 더 높기 때문에 검색의 방법역시 마이크로 블로그의 가치를 높일 수 있는 검색 시스템이 필요하다

또 마이크로 블로그의 포스팅 내용을 분석하면 리스크 상황이나 트렌드를 읽을 수 있기 때문에 소셜분석도구들을 이용하여 포스팅 내용을 분석하여 의미 있는 데이터로 가공할 수 있다

Policy & Compliance Rule

마이크로 블로그의 기업 도입은 정보 보안의 문제를 해결해야한다. 기업 내부로는 특정 그룹 구성원들간에만 커뮤니케이션이 필요한 경우가 있고 기업 밖으로 배포 되는 정보역시 기업의 보안 정책에 따라서 선별적으로 배포 되어야 한다. Policy & Compliance 컴포넌트는 보안 정책에 따라 이 두가지 부분을 커버한다.

(1)    Selective publishing

직원의 아이디를 연동하여 외부 마이크로 블로그(트위터)로 배포 하고자 할 때, 직원이 선별적으로 외부에 배포하는 글을 선택하거나 또는 시스템에서 보안 정책에 위배되는 키키워드 있을 때 이를 필터링하게 해주는 선별적 배포 기능이다.

(2)    Multilevel access & grouping

임원과 일반 직원 또는 부서(예를 들어 HR부서) 내부에서만 다루어야 하는 정보가 있기 떼문에 특정 그룹이나 조직 단위로 커뮤니케이션을 할 수 있게 한다

Micro blog (Public)

외부 마이크로 블로그 시스템으로, 기업 홍보와 같은 마케팅을 위해서 기업 내부의 포스팅 메세지가 기업 외부의 일반 고객이 사용하는 마이크로 블로그 시스템으로 메시지가 배포 되는 대상이다

기업에서 마이크로 블로그 도입 Challenge

 문화의 변경

마이크로 블로그의 도입은 단순한 IT 시스템의 도입이 아니다. IT 시스템은 정해진 프로세스에 직원들이 프로세스의 구성원으로써 주어진 역할을 수행하면 됬지만, 마이크로 블로그의 도입은 정형화된 프로세스에서 벗어나 직원에게 새로운 커뮤니케이션 및 정보 저장 도구를 주어줌으로써 창의력 발휘를 통해서 업무 생산성의 혁신을 불러오고자 하는데 있다.

 이를 위해서는 마이크로 블로그를 이용한 수평적 그리고 비정형적인 커뮤니케이션 스타일의 도입이라는 문화적인 변경이 필요하다. 이는 관리 지향적인 조직 입장에서 이해당사자들의 설득이 필요한 하나의 도전 과제이다.

 정보 보안

마이크로 블로그에 저장되는 내용들은 업무의 진행상태, 개인의 상태등에 대한 정보로 기업의 비밀에 해당하는 내용이다. 이러한 내용이 유출되지 않도록 보안을 유지해야 하며, 반대로 마이크로 블로그의 장점은 오픈된 환경에서 오는 참여에 있기 때문에 보안의 폐쇄성이 원래 마이크로 블로그의 특징을 해치지 않도록 해야 한다.

 또한 구축하는 국가에 따라서 법률에 접촉되는 여부를 검토해야 한다. 예를 들어 미국의 Sox 법에 의하면 사내 커뮤니케이션 내용은 최소 7년간 보장/유지 해야한다는 내용이 있기 때문에 포스팅 데이터에 대한 유지 역시 정보 보안 부분의 도전 과제에 해당한다.

 구축

마이크로 블로그 시스템이 기업에 도입되기 시작한 것은 근 1년 이내이다. 그렇기 때문에 이렇다할 기업용 마이크로 블로그 시스템이 많지도 않을뿐더러, 각 기업의 구축 요건을 충족시키지도 않고 기존 기업 시스템과의 통합성도 떨어지기 때문에 구축에 있어서 적절한 솔루션을 찾고 커스터마이징하는 것이 큰 과제중의 하나이다

구축 전략

앞서 마이크로 블로그의 활용 방법과 얻을 수 있는 장점 그리고 이를 위한 아키텍쳐에 대해서 설명하였다. 물론 아키텍쳐에 제안된 모든 부분을 처음부터 구축할 수 있다면 가장 좋겠지만, 모든 것이 구축되었다고 해서 모든 장점을 얻을 수 있는 것은 아니다.

 기업의 문화를 바꿔야 하는 일인 만큼, 기대했던 효과가 한꺼번에 나타나지 않을 수 있고, 기업의 업무 환경이나 시스템 환경이 변화할 수 있기 때문에 단계적으로 시스템을 구축하는 것을 권장한다

1단계 마이크로 블로그 시스템의 구축

 첫번째 단계에서는 가장 기본적인 마이크로 블로그 시스템을 구축한다. 필수적인 기능으로는 IDM 시스템 연동,모바일 인터페이스 제공이다. 이 두가지 기능만 가지고도 마이크로 블로그를 서비스할 수 있고 대부분의 장점을 시험할 수 있다

2단계 활성화

구축이 완료된 후에는 활성화 단계로 기업의 문화를 마이크로 블로그를 사용하는 형태로 바꿔 나가면서 마이크로 블로그를 이용한 커뮤니케이션을 활성화 한다. 이 단계가 지나면, 시스템에 추가적으로 필요한 기능이 선별된다

3단계 확장

시스템이 활성화 되면 기능을 확장한다. 이미지 포스팅, 동영상 포스팅과 같은 기능을 추가하여 마이크로 블로그 시스템의 활용성을 높이고, 검색엔진, 소셜분석기능등을 구축하여 활성화를 통해서 축적된 정보를 재가공하여 그 가치를 높인다

4단계 새로운 모델 구축 및 확장

4단계에서는 전통적인 마이크로 블로그 시스템의 한계를 벗어나서 기업 업무 형태에 특화된 자체적인 확장 모델을 개발한다. 현장 근무가 많은 영업 조직의 경우 LBS (Location Based Service:GPS등을 이용한 위치 정보 시스템)과 연계하여 Status 정보에 개인의 위치 정보를 표시하거나 위험한 현장 업무가 많은 건설/건축 업무의 경우 개인의 건강 상태나 재해 여부를 Status로 표시하여 근로자가 위험에 쳐했을 때, 구난 요청을 자동으로 보낼 수 있는 시나리오등이 이에 속한다.

저작자 표시
신고

The RESTful Soa Datagrid with Oracle
View more documents from Emiliano Pecis.


Coherence를 캐슁으로 실제 구축한것이 흥미롭다.
다음 아키텍쳐 구축할때 참고할것
신고

REST Overview (Draft)

아키텍쳐 /WEB 2.0 | 2009.07.01 16:10 | Posted by 조대협
REST에 대한 기본적인 설명 PPT입니다.
REST에 대한 개념 설명, 향상된 REST의 특징 설명, Jersey를 이용한 REST 실제 구현 방법
그리고 REST를 사용하기 위한 ESB 아키텍쳐와 REST의 약점중 하나인 Client STUB을 자동으로 생성하는 방법에 대해서 설명되어 있습니다.
 실제 프로젝트 경험을 통해서 처음 정리한 내용입니다. 아직 DRAFT 버전이라서 내용이 다소 거칠고 논리전개가 미숙한 부분도 있습니다. 의견 주시면 내용을 수정하는데 큰 도움 되겠습니다.



REST Ovewview
View more documents from Byungwook.
저작자 표시
신고

REST 연재-2회 Advanced REST

아키텍쳐 /WEB 2.0 | 2009.06.23 23:57 | Posted by 조대협

2회 - Advanced REST (DRAFT)

 

자바스터디 조대협
(http://bcho.tistory.com)

 

전의 글에서는 기본적인 REST의 개념에 대해서 설명하였다. 그러나 REST 는 HTTP의 장점을 이용하여 좀더 발전된 형태의 구현이 가능하다.

하나의 예로 이 글은  http://www.infoq.com/articles/subbu-allamaraju-rest 를 이용하여 편역하여 설명한다. 

예를 들기위해서 은행의 계좌이체를 하는 시나리오를 가정해서 생각해보자.

1. 인터넷 뱅킹 계좌 이체 시나리오의 구현

STEP 1. 인터넷 뱅킹 시스템에 로그인을 한다.

STEP 2. 사용자 ID로, 해당 사용자가 가지고 있는 계좌 목록을 조회한다.

http://bank.org/accounts?findby=7t676323a 

200 OK
Content-Type: application/xml;charset=UTF-8
 <accounts xmlns="urn:org:bank:accounts">
    <account>
        <id>AZA12093</id>
        <customer-id>7t676323a</customer-id>
        <balance currency="USD">993.95</balance>
    </account>
    <account>
        <id>ADK31242</id>
        <customer-id>7t676323a</customer-id>
        <balance currency="USD">534.62</balance>
    </account>
</accounts>

 사용자 ID 7t76323a에 대해서 두개의 계좌 AZA12093과 ADK31242 가 리턴되고 각 계좌의 잔액이 함께 리턴된다. 각 계좌 번호를 조회했기 때문에 각 계좌의 상세 정보는 http://bank.org/account/AZA12093

http://bank.org/account/ADK31242

STEP 3. 계좌 이체를 하는 시나리오를 보면

POST /transfers
Host: bank.org
Content-Type: application/xml;charset=UTF-8
<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

AZA12093에서 ADK31242로 100 USD를 이체하는 것을 HTTP POST를 통해서 보낸다.계좌 이체가 성공하면 다음과 같은 결과값이 리턴된다.

201 Created
Content-Type: application/xml;charset=UTF-8
<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <id>transfer:XTA8763</id>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

이때 주의해서 볼 것은 리턴값이 HTTP 200이 아니라 HTTP 201이다. 이 시스템의 경우 계좌이체가 바로 발생하는 것이 아니라 비동기적으로 나중에 발생하는 형태로 가정하기 때문에, 계좌 이체 요청이 접수되었다라는 의미로 HTTP 201 Created를 리턴하고 이체 신청 번호 XTA8763을 리턴한다. 

STEP 4. 하루가 지난후에, 계좌 이체가 된 내용을 다시 확인해보면

http://bank.org/check/XTA8763

GET /check/XTA8763
Host: bank.org 
200 OK
Content-Type: application/xml;charset=UTF-8
<status xmlns="urn:org:bank:accounts">
    <code>01</code>
    <message xml:lang="en">Pending</message>
</status>

 해당 계좌 이체 요청이 Pending이 되어 있는 것으로 나타난다.

 2. 진보된 형태의 REST를 이용한 인터넷 뱅킹 계좌이체 시나리오의 구현

언뜻 보면 상당히 잘 구현된 형태의 REST처럼 보이지만, 이는 실제 REST의 장점을 제대로 살린 아키텍쳐라고 볼 수 없다.

REST는

첫번째로 URI를 이용한 자원의 식별이 가능해야 하고,

두번째로 HTTP 프로토콜의 여러 기능들 특히 HTTP Header들을 이용해서 리소스에 대한 다양한 접근 방법을 표현할 수 있어야 한다. 예를 들어서 Sync/Async 식의 Message Exchange Pattern, Correlation ID 등을 이용한 CALL BACK, 웹캐쉬를 이용하기 위한 Last Update Time등의 메타 정보를 HTTP HEADER에 정의해야 하며 Contents Type등을 통한 Input과 Output Data Format에 대한 정의가 가능할 수 있다.

세번째로는 링크를 이용한 리소스간의 관계나 현재 리소스에 대한 상태 정보를 표현할 수 있어야 한다

그러면 이 특징을 기반으로 해서 앞에서 작성했던 계좌 이체 시나리오를 재 구현해보자

STEP 1. 인터넷 뱅킹 시스템에 로그인을 한다.

STEP 2. 사용자 ID로, 해당 사용자가 가지고 있는 계좌 목록을 조회한다.

200 OK
Content-Type: application/vnd.bank.org.account+xml;charset=UTF-8
<accounts xmlns="urn:org:bank:accounts">
    <account>
        <id>AZA12093</id>
        <link href="http://bank.org/account/AZA12093" rel="self"/>
        <link rel="http://bank.org/rel/transfer edit"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>
        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>
        <balance currency="USD">993.95</balance>
    </account>
    <account>
        <id>ADK31242</id>
        <link href="http://bank.org/account/ADK31242" rel="self"/>
        <link rel="http://bank.org/rel/transfer"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>
        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>
        <balance currency="USD">534.62</balance>
    </account>
</accounts>

앞서 설명한것과 다소 다른 형태의 리턴값이 오게되는데, 먼저 살펴볼 부분은 Content-Type이다. : application/vnd.bank.org.account+xml; 리턴 형태의 Content-Type이 리턴된다. 먼저 +xml은 이 문서의 포맷이 xml임을 의미하며 vnd.bank.org.account는 리턴 데이터의 구조를 정의한다. (마치 XML 스키마와 같이, 실제로 UNIQUE한 이름으로 INPUT또는 OUTPUT으로 사용되는 XML 스키마의 이름에 ID를 부여해서 사용하면, REST의 약점중의 하나인 데이터 형의 미정의에 대한 약점을 보완할 수 있다. )

 또다른 변화점은 LINK부분이 추가되었다는 것이다. 이 LINK는 현재 자원의 상태가 어떤 상태로 변화될 수 있으며, 상태를 변화시키기 위해서는 어떤 URI를 이용하면 된다는 것을 설명한다. 또는 이 자원과 관련성이 있는 다른 자원에 대한 연관 관계를 표현하며 호출시에 리턴되는 데이터 형태에 대해서 Content-Type으로 정의할 수 있다. 이렇게 RETURN되는 메시지 자체에 다른 자원으로의 연결 상태와 데이터 형태등이 정의되면 서비스에 대한 별도의 정의가 없이도, 자원에 대한 사용 방법과 관계를 알 수 있기 때문에 이러한 특성을 REST에서는 self-descriptive message라고 한다.

 <account>

        <id>ADK31242</id>
        <link href="http://bank.org/account/ADK31242" rel="self" type=”application/vnd.bank.org.account+xml”/>
        <link rel="http://bank.org/rel/transfer"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>
        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>
        <balance currency="USD">534.62</balance>

이 부분을 살펴보면 세가지 변화 상태를 볼 수 있다. Self와 http://bank.org/rel/transfer 그리고 http://bank.org/rel/customer 이다.

첫번째로 http://bank.org/rel/transfer 로 이 계좌에 대해서 “계좌 이체”를 할 수 있는 관계(또는 기능)을 정의하며, 계좌 이체를 하기 위해서는  http://bank.org/transfers URL에 보내면 되고 리턴값은 application/vnd.bank.org.transfer+xml 형태가 된다.

두번째 self는 이 Account 자체에 대한 좀더 제사한 정보를 나타내며 http://bank.org/account/ADK31242 를 통해서 조회할 수 있으며 리턴 되는 데이터 형태는 application/vnd.bank.org.account+xml 로 리턴 됨을 정의한다.

세번째 http://bank.org/rel/customer 는 고객 정보를 나타내며 http://bank.org/customer/7t676323a 를 통해서 조회가 가능하고 리턴되는 데이터 형태는 application/vnd.bank.org.customer+xml 이 된다.

STEP 3. 실제로 계좌 이체를 수행한다.

STEP 2에서 리턴 받은 transfer 관계의 URL로 아래와 같은 데이터를 전송한다.

POST /transfers
Host: bank.org
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8
<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>
 

 리턴값은 아래와 같다.

201 Created
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8 
<transfer xmlns="urn:org:bank:accounts">
    <link rel="self"
          href="http://bank.org/transfer/XTA8763"/>
    <link rel="http://bank.org/rel/transfer/from"
          type="application/vnd.bank.org.account+xml"
          href="http://bank.org/account/AZA12093"/>
    <link rel="http://bank.org/rel/transfer/to"
          type="application/vnd.bank.org.account+xml"
          href="http://bank.org/account/ADK31242"/>
    <link rel="http://bank.org/rel/transfer/status"
          type="application/vnd.bank.org.status+xml"
          href="http://bank.org/check/XTA8763"/>
    <id>transfer:XTA8763</id>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

 STEP 4. 계좌 이체 진행 상태를 확인한다.

계좌 이체 진행 상태를 확인하기 위해서는 STEP 3에서 리턴된 http://bank.org/check/XTA8763 을 이용하여 확인할 수 있다.

결론

사실 여기서 언급하고자 한 부분은 HTTP의 Content-Type을 이용한 데이터 타입의 정의와 Link를 이용한 리소스간의 관계 정의 방법이다. 많은 REST 관련글을 보면 비슷한 사상들을 가지고는 있지만 아직 “이거다” 하는 식의 표준 디자인 방법은 존재하지 않는다.

위의 예제에서도 Content-Type을 통해서 In/out data format을 정의할 수 는 있지만 고민해보면 Link에 정의된 type만으로는 out(return) data format을 정의할 수 있을지 몰라도 input에 대한 정의는 빠져 있다. 또한 다른 디자인에서는 XML의 namespace의 URI에 실제 XML Scheme의 URI를 정의해서 데이터 타입을 정의하는 방법론도 있다.

 또한 Link를 사용하는 방법은 프로토콜 차원에서는 리소스간의 관계를 정의를 하는것이라서 언뜻 보면 좋아보일 지는 모르지만 실제 구현시에는 여러가지 제약사항을 만들어 낼 수 있다.

이 글은 HTTP의 좀더 활용을 통해서 좀더 발전된 형태의 REST 디자인 방법의 하나의 예시를 설명한 것 뿐이고, 좀더 실용적인 REST 디자인은 더 많은 고려가 필요하리라 생각된다.

=======

Comment

사실 본인도 Advanced 스타일의 REST 디자인에 대해 정리를 하기위해서 작성한 글이라서 내용이 다소 떨어지더라도,  아직까지 다소 정리되지 않은 형태의 글임을 이해해주시기 바랍니다. 다음에 기회가 되면 Advanced Style 특히 LINK와 Data type 대해서는 다시 한번 다루기로 하겠습니다. 다음 연재에서는 실제로 REST를 JAVA에서 구현하는 방법에 대해서 알아보겠습니다.

 

저작자 표시
신고



문뜩 궁금해졌습니다. 왜 많은 사람들이 이런 협업에 참여하는지..
1 번 - 온라인 상에 네임 밸류(명성)을 쌓기 위해서
2 번 - 그냥 재미로
3 번 - 지식을 공유하고 싶어서
4 번 - 지금까지 지식을 정리할려고
5 번 - 인맥을 만들어 볼라고
6 번 - 기타


결과


신고
Google Apps - Office 류 및 협업에 사용
Google Groups - 메일링 리스트.
http://twtpoll.com - Survey
http://twitter.com - 마이크로 블로깅
http://facebook.com - 커뮤니티 사이트/ 친구 관리
http://linkein.com - 기술 인맥 관리
http://bit.ly - 북마킹
http://slideshare.com - PPT 파일 쉐어
http://expertjava.blogspot.com/ - 구글 블로그. 영문인데 시작했다가 한글 블로그로.. 

한국 사이트
http://bcho.tistory.com
http://www.me2day.net 마이크로 블로깅
http://www.hanrss.com RSS Reader
저작자 표시
신고
TAG web 2.0

별 서비스가 다있군요.

아키텍쳐 /WEB 2.0 | 2009.06.23 09:28 | Posted by 조대협
http://disqus.com/

블로그 Comment 만 전문으로 처리하는 서비스랍니다. 제가 쓴 Comment만 모아서 볼 수 있고, 댓글이 달리면 메일로 전송되는군요.
신고

REST 관련 강좌

아키텍쳐 /WEB 2.0 | 2009.06.03 09:53 | Posted by 조대협
http://www.infoq.com/presentations/REST-Stuart-Charlton Enterprise 에서의 REST... 성숙도가 점점 올라가는데.. 장난이 아닌듯. 근데 왜 웹서비스 때 스펙이 난무하는 때가 생각날까?
신고

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

현재 자주 사용하고 있는 WEB 2.0 Tools  (0) 2009.06.23
별 서비스가 다있군요.  (0) 2009.06.23
REST 관련 강좌  (0) 2009.06.03
REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (14) 2009.05.27
AJAX Overview  (1) 2009.04.09
TAG REST
그간 Technical한 내용에 대한 Post가 뜨음 했습니다.
작년과 금년에 걸쳐서 REST 기반의 시스템을 설계와 구현을 하였습니다. 그때 참 REST에 대한 이해가 잘못되어 가고 있구나, 그리고 REST에도 생각할것이 참 많구나 하는 생각을 하고 꼭 정리해야지 정리해야지 했는데... 몇달이 지난 지금에야 시작합니다.

총 4회의 연재로 구성됩니다.
1회-REST 아키텍쳐에 대한 소개
REST가 무엇인지에 대해 간단한 소개와 REST 기술에 대한 경향을 알아봅니다.
2회-고도화된 REST 아키텍쳐
Roy Fielding이 소개한 진짜 고도화된 REST에 대한 아키텍쳐를 좀더 깊게 알아봅니다.
3회-REST 구현
REST 구현 스펙인 JAX-RS (JSR-311) 기반의 Jersey 프레임웍을 통한 REST 서비스 구현 방법에 대해서 알아봅니다.
4회-REST 아키텍쳐에 대한 설계
REST 서비스 자체뿐만 아니라 ESB와 WebServer등을 이용한 REST 아키텍쳐에 대한 설계 방법과, REST의 단점인 Service Contract과 Stub을 어떻게 관리하고 코드 생성을 할것인지에 대해서 알아보겠습니다.

시간이 나는데로 정리할려고 하는데.. 써놓고 보니 참 크게 범위를 잡았나 싶네요.
기고 내용에 대한 피드백이나 토론은 항시 환영합니다.

저작자 표시
신고

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

별 서비스가 다있군요.  (0) 2009.06.23
REST 관련 강좌  (0) 2009.06.03
REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (14) 2009.05.27
AJAX Overview  (1) 2009.04.09
REST의 반격?  (0) 2008.12.08

REST 연재-1회 REST 아키텍쳐의 기본

아키텍쳐 /WEB 2.0 | 2009.05.27 23:20 | Posted by 조대협

1회 – REST 아키텍쳐에 대한 기본(DRAFT)

자바스터디 조대협
http://bcho.tistory.com

 

REST 아키텍쳐

REST는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었다. 현재의 아키텍쳐가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했기 때문에, 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐를 소개했는데 그것이 바로 Representational safe transfer (REST)이다. 

Basic of REST 

한마디로 REST를 정리하면 HTTP URI + HTTP Method 이다. URI로 대상 자원을 명시하고 Method로 해당 자원에 대한 행위를 정의한다. 

Resource

REST의 가장 큰 특징중의 하나가 모든 자원을 Resource 즉 자원으로 표현한다는 것이다. 이 Resource는 HTTP URL에 의해서 표현된다. 예를 들어 javastudy 사이트의 bcho 라는 사용자를 표현하면  http://www.javastudy.co.kr/users/bcho 로 표현이 가능하고, 서울 강남구 사무실의 9층의 HP프린터를 표현할때는 http://printers/localtion/seoul/kangnamgu/9f/hp 식으로 표현을 한다. 이로써 HTTP URI를 통해서 모든 Resource를 표현이 가능하다. 

Action

그렇다면 해당 자원에 대한 행동은 어떻게 표현할것인가? 이는 HTTP Method를 사용한다.

l       자바스터디 사이트의 bcho에 대한 회원 정보를 가지고 오고 싶을때는
URI : http://www.javastudy.co.kr/users/bcho
Method : GET  

l       또는 해당 회원을 생성하고 싶을 때
URI : http://www.javastudy.co.kr/users/bcho
Method : POST
PayLoad
 <payload>
  <name>조대협</name>
     :
 </payload>

l       해당 회원을 삭제하고 싶을 때
URI : http://www.javastudy.co.kr/users/bcho
Method : DELETE

l       해당 회원에 대한 정보를 변경하고 싶을 때
URI : http://www.javastudy.co.kr/users/bcho
Method : PUT
PayLoad
 <payload>
  <name>조대협</name>
    :
 </payload>

HTTP 프로토콜에 정의된 4개의 메서드들이 자원(Resource)에 대한 CRUD를 정의한다.

 HTTP Method 의미   
 POST Create   
 GET Select   
 PUT  Create or Update  
 DELETE Delete   

REST 문제점

그런데 문제가 있다. 우리가 사용할 수 있는 메서드가 4가지 밖에 없다는 것이다. 예를 들어 send email이라던가, Log write와 같은 메서드들은 HTTP Method로 표현하기가 모호해진다.

기존의 프로그래밍 스타일이 Function이나 Method를 중심으로 한 행위 중심적인 접근이었기 때문에, REST가 지향하고 있는 자원 기반의 접근에 맞지 않는 것이다. 오히려 DBMS와 같이 CRUD를 가지고 있는 자원에 대해서는 적절하게 적용된다. 이런 이유가 REST를 단순하게 프로토콜이라고 부르지 않고 아키텍쳐라고 정의한 이유이다. 

그렇다면 이 문제를 어떻게 해결해야 할 것인가?

사실 CRUD만으로 모든 행위를 표현할 수 는 없다. Control성이나 함수성의 의미를 갖는 것들을 표현해야 하는데, 이런 경우는 HTTP/PUT이나 POST 메서드를 사용하거나 또는 함수에 대한 의미를 재해석하는 접근이 필요한데. Send Mail을 예를 들어보면 “메일을 보낸다” 라는 행위를 “누구한테 보내는 메일을 생성한다” 라는 의미로 바꾸면 다음과 같은 표현이 가능하다.  HTTP/POST http://www.xxx./sendmail/to/{emailaddress}

 그래도 문맥상으로 의미 변환이 불가능한 경우가 생긴다.

이런 경우는 HTTP/PUT과 URI를 사용하여 control의 의미를 부여한다. 사용자 ID bcho에 대한 등급 변경을 하는 경우는 다음과 같이 표현할 수 있다.

예를 들어 http://www.xxx/users/bcho/upgrade 

사실상 REST 기반의 아키텍쳐를 설계하려면 가장 어려운 것이 이 URI를 어떻게 정의하는 것이다. REST의 장점중 하나는 이 URI와 HTTP Method만으로도 쉽게 의미를 파악할 수 있다는 것이기 때문에, URI 정의에 많은 노력을 기울이는 것이 좋다 

장단점 

REST 장점

기존의 웹 인프라를 그대로 이용할 수 있다.

가장 큰 장점중의 하나일거다. 기존 HTTP를 그대로 사용하기 때문에, Remote Call을 할때도 방화벽을 새로 뚫어야 하느니등의 요건이 없고, L4등의 로드 밸런서 장비들도 그대로 사용이 가능하다.

.엇.보.다. 웹캐쉬 서버를 그대로 사용할 수 있다. 모든 Resource가 URI로 Unique하게 표현되기 때문에, 웹 캐쉬상에 보관될 수 있고, 특히나 SELECT성의 Operation은 이 캐쉬에 의해서 실제 Biz Transaction을 타지 않고 바로 리턴될 수 있기 때문에, 성능과 리소스 활용 측면에서 어마어마한 장점을 가지고 있다. 

쉽다.

웹서비스와 비교해보면 웹서비스는 스펙이 정말 많다. WS*-I, WS Reliable Messaging, WS Transaction 등등등 스펙 덩어리다. 그러나 REST는 별도의 SPEC이 없다. 보통 Defactor 표준이라고 하는데, HTTP URI와 Method만 잘 지켜서 사용하면 그게 REST다. 

REST 문제점

표준이 없다. 즉 관리가 어렵다.

REST가 요즘 들어 부각되는 이유 자체가 WebService의 복잡성과 그 표준의 난이도 때문에 Non Enterprise 진영 (Google,Yahoo,Amazone) 을 중심으로 집중적으로 소개되었다. 데이터에 대한 의미 자체가 어떤 비즈니스 요건 처럼 Mission Critical 한 요건이 아니었기 때문에 서로 데이터를 전송할 수 있는 정도의 상호 이해 수준의 표준만이 필요했지 Enterprise 수준의 표준도 필요하지 않았고, 벤더들 처럼 이를 주도하는 회사도 없었다.

 단순히 많이 사용하고 암묵적으로 암암리에 생겨난 표준 비스무리 한 것이 있을 뿐이다. (이런 것을 Defactor 표준이라고 부른다.) 

그런데 문제는 정확한 표준이 없다보니, 개발에 있어서 이를 관리하기가 어려워진다는 것이다. 표준을 따르면 몇가지 스펙에 맞춰서 개발 프로세스나 패턴을 만들 수 가 있는데, 이는 표준이 없으니, REST 기반으로 시스템을 설계하자면 사용할 REST에 대한 자체 표준을 정해야 하고, 어떤 경우에는 REST에 대한 잘못된 이해로 인하여 잘못된 REST 아키텍쳐에 이건 REST다 라는 딱지를 붙이는 경우가 많다. 실제로 WEB 2.0의 대표 주자격인 Flickr.com 도 REST의 특성을 살리지 못하면서 RPC 스타일로 디자인한 API를 HTTP + XML을 사용했다는 이유로 Hybrid REST라는 이름을 붙여서 REST 아키텍쳐에 대한 혼란을 초래했다. 

. Flickr의 Hybrid Rest는 어떤 Operation을 처리할 때,

 http://URL/operation?name=operationname 과 같은 형태로 메서드를 Query String으로 넘기는 형태를 사용했다. 언뜻 봐서는 RESTful한 디자인 같지만, 모든 Resource의 URI는 같고 operation을 Query String으로 나눈것에 불과 하기 때문에, 모든 Resource에 Unique 한 URI를 부여하는 REST의 원래 설계 원칙과 벗어난다.

 그런데, 국내에는 이런 형태의 디자인을 REST로 이해하고 있는 사람들이 많은 것 같아서 걱정이고 몇몇 포탈에서도 이런 형태의 서비스를 제공하는 것으로 알고 있다.

 

REST적인 접근과 설계가 필요하다.

위에서도 잠깐 설명했지만,  REST는 WebService와 같은 프로토콜이 아니다. REST는 아키텍쳐이다 Resource를 기반으로 하는 아키텍쳐이기 때문에 시스템 설계도 Rest 에 맞는 설계가 필요하다. 

Alternative Key의 사용

예를 들어 Resource를 표현할 때,  이러한 Resource는 DB의 하나의 Row가 되는 경우가 많은데, DB의 경우는 Primary Key가 복합 Key 형태로 존재하는 경우가 많다. (여러 개의 컬럼이 묶여서 하나의 PK가 되는 경우) DB에서는 유효한 설계일지 몰라도, HTTP URI는 / 에 따라서 계층 구조를 가지기 때문에, 이에 대한 표현이 매우 부자연 스러워진다.

예를 들어 DB의 PK가 “세대주의 주민번호”+”사는 지역”+”본인 이름일 때” DB에서는 이렇게 표현하는 것이 하나 이상할 것이 없으나, REST에서 이를 userinfo/{세대주 주민번호}/{사는 지역}/{본인 이름} 식으로 표현하게 되면 다소 이상한 의미가 부여될 수 있다.

이외에도 resource에 대한 Unique한 Key를 부여하는 것에 여러가지 애로점이 있는데, 이를 해결하는 대안으로는 Alternative Key (AK)를 사용하는 방법이 있다. 의미를 가지지 않은 Unique Value를 Key로 잡아서 DB Table에 AK라는 필드로 잡아서 사용 하는 방법인데. 이미 Google 의 REST도 이러한 AK를 사용하는 아키텍쳐를 채택하고 있다.

그러나 DB에 AK 필드를 추가하는 것은 전체적인 DB설계에 대한 변경을 의미하고 이는 즉 REST를 위해서 전체 시스템의 아키텍쳐에 변화를 준다는 점에서 REST 사용시 아키텍쳐적인 접근의 필요성을 의미한다. 

사실 그외에도 REST적인 설계를 하기 위해서는 Resource간의 관계를 href로 (링크)로 표현하는 기법,Versioning 방법,Naming Rule, ESB를 이용한 Cross cutting concern의 처리와 Routing 등 여러가지 고려 사항이 있으나, 아키텍쳐 설계 방법과 고급 REST에 대해서는 다음 기고 (고도화된 REST 아키텍쳐)에 대해서 논의 하기로 하겠다. 

REST 대한 잘못된 인식

REST = HTTP + XML 프로토콜?

프로젝트 성격상 고도화된 REST 시스템에 대한 설계가 필요했기 때문에 필자가 작년 중반즘에 국내의 한 커뮤니티 사이트에 REST에 대한 토론을 제안한적이 있었는데. 대부분의 사람들의 REST에 대한 이해는 REST는 HTTP를 써서 XML을 보내면 REST라고 생각하고 있었다.

절대 아니다.

REST는 웹의 특성을 잘 활용하여 자원을 리소스로 표현하는 아키텍쳐이다.(프로토콜이 아니다) 물론 HTTP는 사용해야 한다. 그러나 XML은 필수가 아니다. JSON이나 YAML과 같은 다른 표현 언어를 사용해도 무방하다. 리소스에 대한 표현과 웹의 특성을 얼마나 잘 활용했는가가 REST 아키텍쳐를 제대로 이해하는가에 대한 판단 기준이 될것이다. 

이번 글을 쓰는 이유중의 하나도 국내에 제대로된 REST에 대한 기고나 원칙을 설명한 문서가 없는 것 같아서 다소 부족한 글이지만 정리한다. 

REST는 WebService보다 쉽다.?

사실 그렇지도 않다. 맨 바닥에서 개발한다면야 REST가 더 쉽다. 자체 표준을 만들어서 Simple XML로 메시지를 정의해서 단순히 HTTP로만 보내면 되니까.. 그런데 이건 서비스 제공자 입장이다. 서비스를 사용하는 입장에서는 HTTP Client로 요청을 보내서 리턴받은 XML이나 JSON 데이터를 일일이 파싱해서 처리해야 한다.

 그러나 WebService는? 이미 잘 짜여진 표준 때문에, POJO나 JAX-WS등으로 코딩만 하면 자동으로 웹서비스가 생성된다. 무엇보다 WSDL에 의해서 정해진 서비스 Contract에 의해서 Client Stub을 자동으로 생성할 수 있기 때문에, 프로토콜 Spec을 전혀 모르더라도 마치 Java Library를 호출해서 사용하는 것처럼 쉽게 사용할 수 있다. 

본인의 경우에는 REST보다 WebService개발이 더 쉬워 보인다. 가장 쓰기 좋은 것은 복잡도가 낮고 잘 정리된 WS-I 기반의 WebService를 사용하는 것이 가장 간단하고 생산성면에서도 좋다. 

REST 전망

국내에서는 아직 REST에 대한 수요가 그다지 많지는 않다. 복잡도가 높은 시스템 설계를 기피하는 현상때문인지.. 아니면 아직 개방형 시스템에 대한 수요가 많지 않아서인지…

그러나 이미 해외의 유수 사이트들은 REST 기반의 아키텍쳐를 통해서 서비스 하고 있으며 대표적인 Open API 업체중의 하나인 Amazon역시 기존에 WebService로 개발되어 있었던 Open API들을 REST 기반으로 Migration할 계획이다. REST가 Defactor표준이기는 하지만 웹세상에서는 이미 무시하기 어려운 표준으로 자리잡아 가고 있다. 

또한 이렇게 오픈 진영에서 탄생한 REST가 J2EE Spec중의 하나인 JAX-RS로 (JSR311)로 추가되어 다음 JEE6 버전에 포함될 예정이다. (오픈 소스로는 Sun의 Jersey 라는 프레임웍과 Apache CXF에 포함도어 있다. 그리고 Spec화 된다해도 어디까지나 구현 방법에 대한 Spec이지 REST가 가지고 있는 그 자유도는 매우 높다. ) REST에 대한 표준화의 일환으로 WebService의 WSDL과 유사한 WADL이라는 Spec이 나오기는 했지만 REST 서비스의 URI정도를 표현하는 뿐이지, 실제 Operation안에 들어가는 Message의 Scheme등을 표현하고 있지 않고 있기 때문에 여전히 REST에 대한 Service Contract 표준은 없다고 보는 것이 맞을 것이고 이것이 앞으로 장점이 될지 단점이 될지는 판단하기 어렵다. 

결론

REST는 그 단순성과 웹의 특성을 최대한 활용한다는 장점 때문에 해외에서는 이미 급격하게 전파되고 있으며 오픈 진영에서 개발된 기술로는 드물게 표준기술(JSR-311)로 채택되는 사례까지 만들었다. 

그러나 그 높은 자유도 때문에 통제나 관리가 어려워서 아직까지는 Enterprise System에서는 널리 사용되고 있지 않고 서비스 시스템 위주로 사용되고 있으며, 국내에서는 잘못된 REST에 대한 이해 부제와 OPEN API의 미활성화로 아직까지는 잘 사용되고 있지 않다. 

 해외의 여러 유수 서비스 업체들이 이미 REST 기반의 서비스를 주류로 하는 만큼 국내 개발자들도 REST에 대해서 준비를 할 때가 되지 않았나 싶다. 

다음 기고에서는 좀더 자세하게 고도화된 REST 아키텍쳐에 대해서 살펴보도록 하겠다.
저작자 표시
신고

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

REST 관련 강좌  (0) 2009.06.03
REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (14) 2009.05.27
AJAX Overview  (1) 2009.04.09
REST의 반격?  (0) 2008.12.08
오픈 환경과 우물안의 개구리....  (0) 2008.09.16

AJAX Overview

아키텍쳐 /WEB 2.0 | 2009.04.09 10:20 | Posted by 조대협
저작자 표시
신고

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (14) 2009.05.27
AJAX Overview  (1) 2009.04.09
REST의 반격?  (0) 2008.12.08
오픈 환경과 우물안의 개구리....  (0) 2008.09.16
Open Social Zembly..  (0) 2008.09.16
TAG ajax

REST의 반격?

아키텍쳐 /WEB 2.0 | 2008.12.08 14:51 | Posted by 조대협
SPEC도 없고, 적당한 구현 프레임웍도 없던 REST가 드디어 반격을 시작하는지?
여기저기서 들려오는 소리가 대부분 REST에 대한 소식이다.
WSDL처럼 REST의 스펙을 정의하는 WADL
REST 프로그래밍 스펙이 JSR 311-JAX RS로 등록이 되고
Sun에서는 JAX RS의 Implementation체인 Jersey (https://jersey.dev.java.net/) 도 있고..
WSDL2.0에서도 REST스펙이 추가 되었다하니
아마 REST 기반의 개발이 가속화 되지 않을까?
금년에는 유난히 REST에 대한 이야기가 많네 그랴..

저작자 표시
신고

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (14) 2009.05.27
AJAX Overview  (1) 2009.04.09
REST의 반격?  (0) 2008.12.08
오픈 환경과 우물안의 개구리....  (0) 2008.09.16
Open Social Zembly..  (0) 2008.09.16

오픈 환경과 우물안의 개구리....

아키텍쳐 /WEB 2.0 | 2008.09.16 17:11 | Posted by 조대협
요즘 오픈 플랫폼에 관련된 프로젝트를 하면서 여기저기 기웃거리고 있는데...
Open Social, Open API. Mash up 플랫폼등..
근데 보면서 느끼는 것이..
Facebook이나 MyFaces와 같은것들이나 여러 사이트에서 제공하는 OPEN API의 인프라를 보면
무섭게도 빨리 발전하고 있다는 것이다.
국내에 잘나간다는 개발자분들 블로그에는 오히려 접하기 힘든 내용이고 국내에서 제공되는 OPEN API도 네이버나 다음에서 그것도 일부만이 제공되지 외국 환경과 같이 강력한 환경이나 이미 널리 전파되어 있는 주요 영역으로 보이지 않는다.
오히려 이런점이 블루 오션이 되지 않을까? 반대로 아래 포스트에서 언급한데로 포탈벤더의 지배력이 강해서 일까??

자바스크립트에 국내 개발자들이 약한것도 하나 이유가 되지 않을까도 싶고..
이미 GLOBAL IT는 오픈 환경으로 움직이기 시작했고.. 이게 Enterprise 에 적용되는 것도 그리 멀지 않았을것 같은데..

지속적으로 관심을 기울여 봐야 겠다..
신고

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (14) 2009.05.27
AJAX Overview  (1) 2009.04.09
REST의 반격?  (0) 2008.12.08
오픈 환경과 우물안의 개구리....  (0) 2008.09.16
Open Social Zembly..  (0) 2008.09.16

Open Social Zembly..

아키텍쳐 /WEB 2.0 | 2008.09.16 08:54 | Posted by 조대협
한국이 조용하고 있는 동안.
외국에서는 Open Social 관련 서비스들이 쏟아지는구나...

워낙 포탈이나 서비스 업체의 영향력이 강한 나라라서..
오히려 이런 오픈 사상이 전파되는 것이 느린것도 같고..

이건 Zembly 데모


신고

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (14) 2009.05.27
AJAX Overview  (1) 2009.04.09
REST의 반격?  (0) 2008.12.08
오픈 환경과 우물안의 개구리....  (0) 2008.09.16
Open Social Zembly..  (0) 2008.09.16