#PARAN SILVERLIGHT#
  • Tistory
    • 관리자
    • 글쓰기
Carousel 01
Carousel 02
Previous Next

'SOA BPM'에 해당되는 글 22건

  • 2012.11.12 Web API Design : 개발자에게 사랑받는 API 만들기
  • 2011.12.02 SOA의 이해(WCF WebService)
  • 2011.06.16 REST 알아보기 - 2부, 웹에서 뭐가 그리도 좋을까?
  • 2011.06.16 REST 알아보기 - 1부, 연동의 역사 2
  • 2009.04.09 SOAP REST
  • 2009.04.09 SOAP
  • 2009.04.02 WSDL(Web Services Description Language)
  • 2009.04.01 REST(Representational State Transfer) 1
  • 2009.04.01 BPEL(Business Process Execution Language)
  • 2009.04.01 MRP(Material Requirements Planning)

Web API Design : 개발자에게 사랑받는 API 만들기

SOA BPM 2012. 11. 12. 16:51

기업 및 개발자들에게 API 제품 및 기술을 공급하는 Apigee는 Web API 설계에 관한 무료 책 "Web API Design : Crafting Interfaces that Developers Love"를 발표했다.

여기에는 좋은 API를 설계하기 위한 Best practices가 정리되어 있어, API를 도입하는 분들에게는 좋은 노하우를 제공하고 있어, 본 포스트에서는 "Web API Design"이라는 책을 참고하여 좋은 API 설계란 무엇인지에 대해서 정리해 본다.


1. 기본 URL에는 동사가 아닌 명사를 사용하며, 리소스마다 2개의 기본 URL을 유지하자.
- 심플한 것이 가장 보기 좋다.

예) /dogs(Collection), /dogs/1234(Element)

2. HTTP 동사(POST, GET, PUT, DELETE)를 사용해 집합(컬렉션)이나 개별 요소를 오퍼레이션 하자.
- POST(create), GET(read), PUT(update), DELETE(delete)를 명심하자.

3. 복수형 명사와 구체적인 이름을 사용하라.
- 단수보다 복수 형태를 사용하는 편이, 그리고 추상적인 이름보다 구체적인 이름을 사용하는 편이, 직관적인 API다.
예)Foursquare : /checkins, GroupOn : /deals, Zappos : /Product

4. 자원 간의 관계를 간단하게 하여 URL 계층이 깊어지는 것을 피하자.
- 자원간의 관계, 매개 변수 및 속성과 같은 복잡한 것은 HTTP 물음표 뒤에 가지고 가자.
예) GET /owners/5678/dogs, GET /dogs?color=red&state=running&location=park

5. 오류 처리를 명확하게 해라.
- HTTP 상태코드를 정하고(많아도 안좋음), 개발자들을 위한 오류 메세지 정의, 상세 정보 링크 등을 넣어주면 좋다.
200 - OK
400 - Bad Request
500 - Internal Server Error
201 - Created
304 - Not Modified
404 - Not Found
401 - Unauthorized
403 - Forbidden

- code, message, more_info 필드를 두어서 결과값을 먼저 파악할 수 있도록 한다.
예) {"status" : "401", "message":"Authenticate","code": 20003, 
 "more info": "http://www.twilio.com/docs/errors/20003"}

6. 버전 관리를 해라.
- 접두사 "v"로 버전을 지정하고 1계층에 두자.
- 인터페이스로서 구현이 아님을 강조하기 위해 간단한 정수를 사용하자. 버전 일렬번호는 소수점 쓰지 마라.
- 필요시 헤더에 버전을 디자인할 수도 있다.(단점은 개발자들이 잊을 수 있다.)
  예) GET /v1/dogs

7. 부분적 응답과 페이징 처리를 하라.
- 리턴해 달라는 필드를 지정하려면(부분 응답) 쉼표로 구분된 목록을 사용하자. 
  예) /dogs?fields=name,color,location
- 페이징을 할 경우 상대 위치(offset)와 범위(limit)를 사용, 기본 값은 limit=10&offset=0을 사용한다.
  예) /dogs?limit=25&offset=50

8. 데이터 베이스에 없는 자원에 대한 응답일 경우 동사를 사용하라.
- 리소스가 아닌 응답을 전송하는 경우 명사가 아니라 동사를 사용하는 것이 알기 쉽다. 
- 계산(Calculate), 번역(Translate), 변환(Convert) 등의 경우처럼 알고리즘 계산이나 번역, 환율 변환 등에 요청이 올경우 명사가 아니라 동사를 사용하라.
  예) /convert?from=EUR&to=CNY&amount=100

9. 다양한 형식(컨텐트 타입)을 지원하는 경우 도트 형식의 서식으로 하라.
- JSON과 XML과 같이 API 다른 응답 형식을 지원하는 것을 추천한다.
- 기본 형식은 json이다.
- Accept 헤더에 타입을 지정하거나, URL속에 type 매개변수를 사용할 수 있다. 권장 방식은 명사.type(도트 형식의 서식)으로 하는게 낫다.
  예) dogs.json, /dogs/1234.json

10. 속성(attribute)의 네이밍은 Javascript의 관습을 따르고 카멜 케이스 (CamelCase)를 사용하자.
- 기본값으로 JSON을 사용하고, 속성의 이름은 Javascript의 관습을 따른다. 중간 부분에 대문자를 사용(카멜 케이스)
  예) "createdAt": 1320296464

11. 검색 팁
- 전체 검색은 동사 "search"와 쿼리 매개 변수 "q"를 사용하자.
  예) /search?q=fluffy+fur
- 범위 한정 검색은 /리소스/리소스 ID/리소스?q=XXX(리소스 ID가 5678 인 주인의 개를 검색) 형태로 한다.
  예) /owners/5678/dogs?q=fluffy+fur
- 도트 형식의 서식을 사용하여 검색 결과 형식을 지정하자.
  예) /search.xml?q=fluffy+fur

12. 하위 도메인의 독립적인 API 요청 처리는 여러 개를 만들지 말고 통일하라.
- 여러 기능적으로 독립된 url을 여러개 만들지 말고 모든 API 요청을 하나의 API 하위 도메인에 정리하자. api.company.com 같은 것을 사용하는 것이다.
- developers.company.com 같은 개발자 전용 포털을 만들자.
- 사용자가 브라우저에서 API 하위 도메인을 여는 등 요청에 대한 원하는 정보가 없다면 개발자 포털로 리다이렉트 해라.

13. 예외 처리를 위한 팁
- 클라이언트가 HTTP 오류 코드를 차단하는 경우(Adobe Flash 경우), 응답을 클라이언트에서 먹어버림으로 응용 프로그램 개발자가 오류 코드를 차단하는 기회가 없어진다. 그래서 트위터처럼 suppress_response_codes가 있으면 무조건 200으로 리턴하게 한다.
- 클라이언트가 지원하는 HTTP 메소드가 제한되는 경우 URL에서 method형태로 호출하게 한다.
  예) Create : /dogs?method=post, Read : /dogs, 
 Update : /dogs/1234?method=put&location=park, 
 Delete : /dogs/1234?method=delete

14. 권한 관리(OAuth)는 2.0을 사용하라.
- OAuth 1.0a보다 2.0을 사용하라. 더 안전하고 웹과 모바일 모두 사용자에게 더 나은 경험을 제공한다.

15. API상에서 요청을 구성해보면 아래와 같다.
- Al라는 갈색 개를 생성.
POST /dogs
name=Al&furColor=brown
응답
200 OK
{
"dog": {
"id": "1234"
"name": "Al"
"furColor": "brown"
}
}

- Al의 이름을 Rover로 수정
PUT /dogs/1234
name=Rover
응답
200 OK
{
"dog": {
"id": "1234"
"name": "Rover"
"furColor": "brown"
}
}

- 특정 개에 관하여 조회
GET /dogs/1234
응답
200 OK
{
"dog": {
"id": "1234"
"name": "Rover"
"furColor": "brown"
}
}

- 모든 개에 관해 조회
GET /dogs
응답
200 OK
{
"dogs":
{ "dog": {
"id": "1233"
"name": "Fido"
"furColor": "white"}}
{ "dog": {
"id": "1234"
"name": "Rover"
"furColor": "brown"}}
"_metadata":
[{ "totalCount": 327 "limit"25 "offset": 100}]
}

- Rover개 삭제
DELETE / dogs/1234
응답
200 OK

16. 수다 API 지양하자.
- 간단한 응용 프로그램을 구축하는데, 여러번의 서버 API 호출을 해야 하는 수다스러운 API는 지양해라.
- 완전한 RESTful API를 만들고, 필요에 따라 단축키 및 합성 응답을 제공하는 것을 추천한다.

17. SDK로 API를 보완하라.
- 자기 모순없이 표준에 기초하고 있고, 충분히 문서화 되어 있고, 예제도 충분히 있다면 SDK가 필요 없을 수도 있다. 하지만, API 프로 바이더는 샘플 코드 라이브러리, 소프트웨어 개발 키트 API를 보충하는 것을 추천한다.
- 도메인 지식에 의해 API가 변경되어서는 안된다. SDK를 통해 API를 보완해라.
- SDK는 낮음 품질, 비효율적인 코드를 줄여준다.

18. API Facade Pattern을 API 설계에 고려해라.
- 인터페이스와 API구현체 사이의 가상 레이어가 존재한다.
- 구현은 세 가지 기본적인 단계로 구성된다.
. 이상적인 API를 디자인하라 - URL, 요청 파라미터, 응답, 페이로드, 헤더, 쿼리 파라미터 등. API 디자인은 일관되어야 한다.
. 데이터 스텁을 사용하여 디자인을 구현하라. 이제 API가 내부 시스템에 연결되기 전에 응용 프로그램 개발자는 API를 사용할 수 있으며, 피드백을 줄 수 있다.
. 퍼사드와 내부 시스템 사이에서 중개자 역할 또는 통합을 한다.


출처 : http://mimul.com/pebble/default/2012/08/07/1344315512542.html

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

SOA의 이해(WCF WebService)

SOA BPM 2011. 12. 2. 15:24

 좀 오래된 책이기는 하지만 설명이 자세하게 되어 있어서 .Net FrameWork 3.0을 참고 해서 SOA를 좀 더 이해하게 되었다.

- 프로그래밍의 패러다임 변화
 : Object-Oriented => Component-Based => Service-Oriented(SOA) =>(?)  Resource-Oriented(ROA) / Restful

- SOA 
 :  서비스 지향 아케텍쳐 - 소프트웨어를 기술이 아니, 소프트웨어가 추구하는 목적(업무)의 관점에서 바라보는 것
 :  서비스 -  특정 업무를 부르는 개념 <=   특정 기능이 아님
                 소비자의 관점              <=   개발자의 관점   
 :  WCF   -   SOA를 구현하기 위한 도구      
 :  치킨서비스를 하는 웹 서버(WCF)와 클라이언트(WPF)를 구현 (책을 참고)

WcfService2.zip




 웹서비스의 이해
- 분산 환경이 발전해 온 과정 
 :COM/COBRA => IIOP.DCOM/RMI => JMS/MSMQ => WEB SERVICE

- 이기종 어플리케이션과 시스템간의 통합(EAI) 
 : 표준을 따름 , 동일한 방식과 동일한 프로토콜 사용

- XML 형태의 메시지와 SOAP(Simple Oriented Access Protocol)을 사용
- WSDL : SOAP 서비스를 설명하는 규약

- 닷넷 웹서비스 클라이언트
 : 웹서비스 참조가 완료되면 자동으로 Proxy Class가 생성(reference.cs 파일)
   Proxy Class는 SOAP 메시지를 만들어서 웹서비스에 전달 / 결과를 받아서 리턴


저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

REST 알아보기 - 2부, 웹에서 뭐가 그리도 좋을까?

SOA BPM 2011. 6. 16. 08:51

이 글은 REST에 대해 정리하는 두편의 글중 두번째 글입니다. 따라서 1부("REST 알아보기 - 1부, 연동의 역사", 클릭)를 읽지 않으신 분은 먼저 1부부터 보시고 본 글을 읽어주시길 바랍니다. 1부 글은 왠만하면 반복하지 않을테니까 말입니다.


[1부를 아주 간단히 요약해버리자면]

REST도 네트웍에 물려있는 서비스 자원들간의 연동이라는 이슈에서 나온 것으로써, 1부에서 네트웍에서 연동의 역사를 한번 나름대로 짚어보았습니다. RPC - CORBA - RMI - SOAP - REST에 이르기까지, 그 기술들이 진화하며 해결한 부분들을 파악했습니다.

REST는 "Representaional State Transfer"의 약자로써, 웹프로토콜(HTTP)을 활용하여, Resource 중심으로 연동 인터페이스를 정의하고 사용하는 방법을 제안한 것입니다. 한마디로 웹(HTTP) 프로토콜을 최대한 그대로 사용하여, Open API를 만드는 스타일가이드라고 할 수 있습니다.

그러나, 이런 개념적인 얘기로는 개발자가 아니신 분들이라면 잘 이해가 가지 않을 것입니다. 그래서 오늘은 좀 더 명확하게 이해할 수 있도록 REST가 좋은 이유를 구체적으로 설명하도록 하겠습니다.


[REST는 뭐가 그리 좋은가?]

1. 웹친화적이다.
이미 웹 친화적이라는 말씀은 서두에서 드렸으므로, 더이상 설명할 필요는 없을 것 같습니다. 요새는 방화벽을 넘어서 연동해야 하는 경우가 허다합니다. 그럴때 SOAP이나 REST를 제외한 다른 연동프로토콜들을 대부분 방화벽에서 문제를 야기합니다.
(출처: http://olivecentre.org.uk)


2. 웹서버로 해결이 가능하다
REST는 HTTP 동사를 그대로 사용합니다. 앞서서 얘기했듯이 HTTP request, response 전부 재활용합니다. 심지어 Error 상태 code까지도 말입니다. 게다가 결과를 주고받는 것도 웹브라우저에서 지원되는 XML 또는 JSON입니다. (JSON은 자바스크립트에서 XML보다 데이타를 쉽게 전달하는 방법이지요) 따라서 대부분의 서버프로그램을 제외하면 REST를 운용할 수 있는환경이 웹서버하나로 해결되는 셈입니다. (참고로 요새 공유기, IP전화기, 각종 셋탑 등 모든 IP장비는 웹을 통해 설정을 할 수 있게 되어 있습니다. 그 얘기는 그런 장비들에 웹서버들이 모두 들어간다는 것입니다.)
(출처: http://www.symbian-freeware.com)

3. 캐슁(Caching)도 된다
REST 방식을 제대로 적용한다면, 즉 ReSTful하게 잘 만든다면, 웹에서 캐쉬기능도 그대로 활용할 수 있습니다. 아시다시피, 웹에서는 동일한 내용을 계속조회할때 중간노드에서 프락시를 사용하여 트래픽을 줄이기도 합니다. (IE 브라우저 옵션에 보시면 HTTP-Proxy 설정부분이 있는데 바로 그 부분을 말합니다) 그런데, 웹서비스도 알고보면 업데이트보다는 조회가 훨씬 많다는 것이고, 그 조회의 대답은 앞단에서 Proxy가 캐쉬한 값을 전달해서 처리할 수도 있다는 얘기입니다. 잘 사용하면 서버 부하, Response time을 확 줄일 수 있겠죠.
(출처: http://knowledgehub.zeus.com/media/caching_01.png)


4. 개발자에게 상당히 직관적이다.
이것도 앞에서 말씀드렸던 내용인데, HTTP 동사를 그대로 사용하고, 예외코드도 그대로 사용하므로, 개발자 관점에서는 상당히 익숙하고 직관적으로 이해할 수 있습니다. 즉 REST로 OpenAPI를 제공하면, 매개변수와 URI에 집중하면 되고, 함수를 실제 호출하고 사용하는 방식에 있어서, 많은 부분 RESTful하다는 얘기로 설명이 된다는 부분입니다.
(출처: http://4.bp.blogspot.com)


5. 컨텐츠 협상(Negotiation)이 가능하다.
아니 프로그램에서 웬 협상하실 겁니다. 그런데, Open API는 클라이언트 서버처럼 Tight couple된 관계가 아니라서, 어떤 놈이 HTTP-request를 날릴지 모르는 것이고, 그 놈이 서버에서 제공해주는 HTTP-response를 다 알아 먹을 수 있는지도 알 수 없다는 점입니다. 즉, Response가 기본 한글인데, 함수를 호출한 놈은 영문만 받아들 일 수 있다면, HTTP에서는 컨텐츠 협상을 통해, 이 요구에 대해서는 좀 다르게 응답을 할 수도 있는 것이지요. (아마 HTTP request를 할때, 본문에서 Accept-Language header를 활용하여 이런 협상을 하게되겠죠)
(출처: http://www.isoc.org/inet96)

일반적으로 서버 프로그램하면서 이런 것까지 다 고려해서, 확장성을 확보하기는 사실 어렵습니다. 기껏 한다고 해봐야, if절이나 예외처리(Try catch) 몇개로 해결할 뿐이죠. 그런데 HTTP는 언어나 미디어타입(MIME)까지 기본적으로 협상할 수 있게 왁꾸가 되어 있는 것입니다. 제게는 이런 Feature가 참 아름다운데, 그렇지 않으신지요 ^^;
(출처: http://www.bbc.co.uk)


6. 웹 기술은 다 써먹을 수 있다.
데이타를 주고받는데 가장 확장성있는 방법은 누구나 인정하듯 XML입니다. 그래서 웹에서 XML은 엄청 널리 쓰이고 있습니다. REST에서는 결과값을 전달하는 데 있어서 복잡한 내용도, 구조적인 결과도 XML로 처리할 수 있는 것입니다.
(출처: http://esto.nasa.gov)

아울러 웹은 HTTP-response로 전달될 결과값이, 그리 복잡한 구조도 아니고, 아주 간편한 처리를 할 수 있도록 할 경우 JSON을 쓰기도 합니다. (JSON은 JavaScript에서 손쉽게 구조적인 값을 주고받는 방식이지요) REST에서도 이 방식도 그대로 사용할 수 있습니다. (JSON을 쓸경우, HTTP request의 헤더중에 "Accept: application/json"이 들어가게 되겠지요)

결국 REST에서는 널리 사용되는 웹기술(HTTP + URI + XHTML + XML + JSON ...)을 그대로 받아들여 OpenAPI를 아주 실용적인 관점에서 접근하게 해주는 셈입니다.


[끝으로 한마디]

제가 설명한 것외에도 HTTP 프로토콜을 사용함으로 얻는 이점은 더 많이 있을 것입니다. HTTP를 아는 사람이라면 새로 배울 필요가 없다, 개발툴, 검증/테스트가 쉽다 등등 말입니다. 그래서 REST는 OpenAPI로 각광받는 것이며, 아울러 계속해서 발전 진화하고 있습니다. WOA(Web oriented architecture)나 WOT(Web of things)같은 게 그발전, 활용도의 극대화 예라고도 할 수 있겠습니다.

아무쪼록 웹하시는 분들, 매쉬업 아이템을 기획하시는 분들은 REST의 기본개념은 알아두시기 바랍니다.




출처 : http://dreamgoer.net/200

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

REST 알아보기 - 1부, 연동의 역사

SOA BPM 2011. 6. 16. 08:50

2000년대 후반부터 웹에서 OPEN API하면 REST가 항상 언급됩니다. 그리고 제가 WOT(Web of things) 소개하면서 쓴 글("왜 WOT인가? - 1부", 클릭)에도, REST가 핵심이라고 했습니다. 그래서 오늘은 웹기반 Open API의 표준 연동방식처럼 회자되는 REST라는 놈에 대해 정리를 해보고자 합니다.

우선 REST는 무엇일까요? REST(Representaional State Transfer의 약자)는 웹프로토콜(HTTP)을 활용하여, Resource 중심으로 연동 인터페이스 구조를 제안한 것입니다. 그런데 리소스 중심이라는 얘기나, HTTP라는 얘기 모두 감이 잘 오지 않을 것입니다. 일단은 웹서비스를 Open API로 연동하는 데 있어서, 어떻게 HTTP를 사용하면 좋다는 스타일 가이드라고만 해두고 REST가 나오기까지의 히스토리를 좀 짚어보겠습니다. 왜냐하면 웹세상 이전으로 돌아가서, 고전적인 시스템(클라이언트-서버)간 연동 문제가 어떻게 해결되어 왔는지 그 실타래를 따라가다보면 REST가 어떻게 Open API의 강자가 되었는지를 저절로 이해하게 되기 때문입니다.



[프로그램간 연동 - 고민의 시작]

개발의 기본은 무엇인가요? 라이브러리화(쉽게 말해 함수화하는 것)입니다. 그렇게 함으로써 소스코드를 쉽게 재활용할 수 있게 하고, 특히 라이브러리를 공유함으로 나혼자가 아니라, 다른 사람들도 이어서 개발을 할 수 있는 기반이 됩니다. 그런데, 이렇게 하는 것도 하나의 컴퓨터에서나 가능할 뿐, 네트웍을 넘어갈 순 없었습니다. 즉 A컴퓨터에서 B의 컴퓨터에 있는 라이브러리를 호출할 수는 없다는 것이었습니다.

그래서 B의 컴에 네트웍을 통해 호출받을 수 있도록 좀 작업을 하기 시작합니다. 그게 소위 RPC 데몬이라는 놈인데, Remote Procedure Call의 약자로 주로 유닉스에서 사용되었었습니다. 하지만 이놈은 보안에도 문제가 좀 있었고, 네트웍 자원 활용이나 함수를 동적으로 사용하는데 있어서도 제약이 있었습니다. (프로그래밍 안해보신 분들은 아래그림보고 그냥 이런게 있구나 하고 넘어가시면 되겠습니다)

(출처: http://www2.cs.uregina.ca)

그래서, 이 문제를 해결하는 김에, 아예 프로그램언어, OS와도 무관하게 해결해보자는 시도가 있게됩니다. 바로 그게 CORBA였습니다. CORBA는 A컴에 있는 C++ 프로그램이, B컴에 있는 자바 서버의 함수도 호출할 수 있게 한다는 뭐 그런 취지였습니다. 원리는 대강 이렇습니다. IIOP라는 프로토콜을 통해서, 프로그램 언어에 상관없이 인터페이스를 정의(IDL)하고, 그걸 기반으로 각 언어에서 CORBA 플랫폼을 통해 개발하면 C++로 짜놓은 함수도, 자바에서 호출할 수 있게 되는 것이었습니다.

(출처: http://img.zdnet.com)

그런데 CORBA는 무겁고 비쌌습니다. (참고로 많이는 아니지만, Iona의 Orbix와 볼랜드의 Visibroker라는 대표적인 Corba 플랫폼을 다 만져볼 기회가 있었습니다.) 클라이언트는 무료였지만, 서버쪽 CORBA 플랫폼은 2000년 초반가격으로도 1억이 넘었습니다. 게다가 연동오버헤드도 무거운 편이어서, 개발해보면 서버쪽 HW도 어느정도 빠방해야 했지요. 결국 프로그램간 연동을 쉽고 경제적으로 하기 위해 나온 놈이 비싸고 쉽지 않았던 겁니다.

그래서 Java 진영에서는 RMI (RPC의 자바버전)를 소개합니다. 제가 NMS 개발하면서 사용해보았는데, 쉽고 아주 편했습니다. 하지만 이 놈도 사내 네트웍에서는 연동이 쉬웠지만 방화벽에서는 늘 상 걸리곤 했습니다. 방화벽은 기본적으로 HTTP만 열어주지요.





[HTTP - 웹서비스 화두를 열다]

그래서 HTTP로 무엇인가 연동하는 방안을 고민했었고, 그게 바로 XML과 HTTP를 결합한 SOAP기반의 웹서비스였습니다. 일단 SOAP은 HTTP를 활용할 수 있므로, 방화벽문제는 어느정도 해결했습니다. 그런데 문제는 여전히 좀 어려웠다는 겁니다. SOAP기반 웹서비스는 근본적으로 서비스지향 구조(Service-Oriented Architecture)로써, SOA라고 불리는데요. 서비스를 자유자재로 정의할 수 있다는 게 매력인 동시에 그만큼 복잡해질 수도 있다는 게 문제였습니다.

즉 서비스를 정의하는 것 자체도, WSDL이란 놈을 만들어 함수명부터 시작해서 매개변수, 결과값까지 세부적인 사항 하나하나를 정의합니다. 그리고 이를 UDDI(인터넷에서 DNS같은 거라고 이해하시면 됩니다)라는 놈에 등록해서 외부에서 발견할 수 있게 하는 구조였습니다.

(출처: http://nuwanbando.com)

그러다가, 서비스지향으로 바라보기 보다는 리소스기반(Resource-Oriented Architecture: ROA)으로 정의하면 어떻겠느냐는 아이디어가 나옵니다. 잘 아시듯, 웹이라는 놈 자체가 리소스기반입니다. 웹에서는 모든 문서, 객체(URI를 통해 가져올 페이지를 표시하지요)를 대상으로 해서, HTTP Get하는 게 기본 조작입니다. 그래서 자원관점으로 보면, 웹에서 사용하는 HTTP Primitive (GET, PUT, POST, DELETE)를 그대로 쓸 수 있지 않겠냐는 생각을 하게 된거죠. 바로 그게 REST인겁니다.

결국 REST는 SOAP기반의 웹서비스인 SOA(Service-Oriented Architecture)와 대비되는 자원기반의 ROA(Resource-oriented Architecture) 연동방식인 것입니다. 참고로 ROA는 더 확장해서 WOA 즉 Web Oriented Architecture로까지 발전됩니다. 아래 그림은 ROA의 대표격인 REST를 포함해서, 이를 더 넓게 그린 WOA를 보여줍니다.


참고로 저는 SOAP시대까지만 프로그램에 손을 대었는지라, REST로 직접 개발을 해본 경험은 없습니다. 대신 REST 책은 한권 읽어보았고, 그걸 기반으로 아는체 하고 있는 겁니다. 따라서 REST 개발자분들께서 댓글을 달아주시면 저와 읽는 분들 모두 다 행복해지겠지요.



[ROA - 생각해보면 그럴싸하다]

SOA에서는 WSDL에 호출할 함수명을 마음대로 정의할 수 있습니다. 즉 id로 이름을 가져오는 웹서비스를 만든다고 할때, getName, retrieveName, findName 모두 사용할 수 있습니다. 그런데 과연 이런 자유도가 중요할까요? 알고보면 이름은 거기서 다 거기인 셈입니다.

REST는 모든 것을 리소스기반으로 보기때문에, 위의 함수(getName, retrieveName, findName)를 만드는데 사용하는 함수명은 HTTP의 Get임이 자명합니다. 그리고 특정 ID로 이름을 입력하려면 HTTP POST, 갱신하려면 HTTP PUT, 삭제하려면 HTTP Delete를 사용하면 될 것입니다. 바로 이 부분에서만 해도, REST는 개발상 굉장히 직관적인 셈입니다.

리소스 관점으로 보는 대표적인 예가 DB입니다. DB안에 있는 것은 모두 리소스입니다. 그러면 DB를 조작하는 데 사용하는 SQL의 Primitive는 무엇이 있습니까? 아래 그림 가운데 있는 insert, select, update, delete입니다.


위에 보시는 것처럼, 각각은 알고보면 HTTP의 기본동사(Primitive)와도 1:1 대응이 됩니다. 그리고 프로그램할때, 특정 변수에 대해 생각해볼 기본조작 함수인 CRUD(Create, Read, Update, Delete)도 알고보면 HTTP 기본동사(Primitive)에 대응이 되는 셈입니다. 즉 REST는 나름 우리가 표준적으로 사용하는 프로그래밍 패러다임과 쉽게 매핑이 된다는 얘기입니다.

※ SDK를 보신 분들이라면, 메쏘드 이름을 떠올려보세요. 객체지향 프로그램을 하는 분들은 다 공감하실 것이, 객체를 생성하거나, 삭제하는 것을 제외하면, 대부분 함수는 Getter와 Setter로 구성된다는 겁니다. 즉 GetXXX, SetXXX식의 함수가 되버리죠. 물론 Go, run, doIt 같은 함수들도 돌리지만, 그게 알고보면 Create, Delete, GetXXX, SetXXX로 구성될 수 있는 것들입니다.



[그러면 매개변수와 결과값은 어떻게 전달해주나요?]

아마 누군가가 벌써 질문하고 있을 겁니다. 기존프로그램에서는 함수라는 게 알고보면 함수명만 있는 게 아니고 매개변수고 있고, 결과값도 있는데 그게 어떻게 처리되냐고 말입니다. 일반적인 함수의 형식은 이렇지요.
  • NameType GetName(String id);

위에서 말한 것처럼, GetName에 해당하는 부분은 HTTP의 GET인 셈입니다. 그리고 Name이라는 부분은 URI를 통해서 이뤄지는데, 아마도 http://abc.com/employee/name?id="ooo" 같은 식으로 HTTP-Request의 GET에서 충분히 표현이 될 것입니다. 그리고 그 결과값(위에서는 NameType)은 형식만 정의하면(보통 XML이나 JSON으로 정의합니다) HTTP response로도 정리가 될 것이구요.

특히 HTTP는 RESPONSE W3C에서 표준 코드로 인터넷에서 발생할 수 있는 상황을 모두 고려하여 정리되어 있습니다. 즉 결과값에서 200OK뿐만 아니라, 다음과 같은 상태 코드들이 나올 수 있고, 그에 대한 대응도 대부분의 브라우저는 다 알고 있습니다. 다시말해 웹개발을 해본 사람들은 누구나 쉽게 이해할 수 있으며, 이에 맞게 대응할 수 있다는 얘기입니다. (아래는 Status code 일부만 표시해본 것입니다)
  • 301 Moved permanently
  • 302 Found
  • 303 See Other
  • 403 Forbidden
  • 404 Not Found
상기의 HTTP-response 코드는 단순해보이지만, Loosely coupled 된 웹을 지켜주는 오랜 경험의 산물입니다. 실상 이 코드에 따라 IE나 파폭, 크롬, 사파리같은 웹브라우저는 알지도 못하는 아프리카의 한 웹사이트에서 오는 가끔 에러를 발생시키는 검증안된 웹 response에도 걸맞게 대응할 수 있는 것입니다.

REST에서는 힘하나 안들이고, 상기의 HTTP 프로토콜에서 제공해주는 메커니즘을 그대로 활용하고 있는 셈입니다.

※ 물론 연동방식을 결정하실때 REST로 하자고만 하면 다 해결되는 것은 아닙니다. REST는 RESTful approach, 즉 하나의 방식이라는 표현을 사용하고 있는데 그 이유는 REST가 HTTP Primitive + URI를 사용하여, HTTP-request를 날리고, HTTP-response를 통해 응답결과를 주고받으라는 방식을 지정했을 뿐, 실제 결과 데이타의 표현형식은 개발자가 알아서 정해야 하기 때문입니다.(보통 XML이나 JSON으로 정합니다) 이 점에서 REST는 나름 꽤 열려있지만, 그만큼 REST 이름만 빌릴 뿐 RESTful하지 않은 OpenAPI가 마구 나올 수 있다는 얘기가 됩니다.



[정리하자면...]

REST는 네트웍상에서 원격에 있는 서버의 서비스(API)를 사용할 수 있게, 그것도 방화벽이라는 제약을 넘어서 가능하게 하자는 취지에서 나왔습니다. 이런 시도는 서비스지향의 SOAP기반의 웹서비스도 있었으나 REST는 좀더 실용적인 접근을 했고, 그 실용성, 이해하기 쉬움, HTTP의 Verb, request, response를 그대로 사용한다는 특징덕에 현재는 가장 각광받는 Open API 방식이 되었습니다.

2부에서는 상기 이유외에도, 아니 상기 이유를 좀 더 구체적으로 명기하여 왜 REST가 OpenAPI의 대명사가 되었는지를 설명하도록 하겠습니다.


출처  : http://dreamgoer.net/199
저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

SOAP REST

SOA BPM 2009. 4. 9. 17:55

SOAP - Simple Object Access Protocol

[#M_더보기|접기|

<간단한 정리>

l        XML 기반의 메시지를 네트워크 상에서 교환하는 형태의 프로토콜로, 전송 프로토콜은 HTTP를 표준 스택으로 사용하고 있다.

l        XML을 근간으로 헤더와 바디를 조합하는 디자인 패턴으로 설계되어있다.

l        플랫폼과 프로그래밍 언어에 독립적이고, HTTP이외의 프로토콜도 사용 가능하며, 프록시와 방화벽에 구애받지 않고 쉽게 통신이 가능하다는 장점을 가진다.

l        반면에 XML태그 형태로 보내기 때문에 COBRA같은 미들웨어 기술과 비교해서 상대적으로 느리다.

 

<참고 자료>

확장성 생성 언어(XML)와 하이퍼텍스트 전송 규약(HTTP) 등을 기반으로 하여 다른 컴퓨터에 있는 데이터나 서비스를 호출하기 위한 통신 규약. 마이크로소프트사와 유저랜드 소프트웨어(UserLand Software)사, 디벨롭멘터(Developmentor)사가 중심이 되어 개발하였다. SOAP에 의한 통신에서는 XML 문서에 봉투(envelope)로 불리는 부대 정보가 붙은 메시지를 HTTP 등의 프로토콜로 교환한다. 서비스를 이용하는 클라이언트와 서비스를 제공하는 서버 쌍방이 SOAP의 생성, 해석 엔진을 가지는 것으로 다른 환경 간에서의 객체 호출을 가능하게 하고 있다. SOAP 1.1에서는 실제로 데이터의 송수신에 사용하는 하위 프로토콜은 현재 널리 보급되어 있는 HTTP나 간이 전자 우편 전송 프로토콜(SMTP), 파일 전송 규약(FTP) 등에서 선택할 수 있게 되어 있어 기업 간에 이용하는 경우에도 방화벽 등을 안전하게 통과할 수 있다. 현재 월드 와이드 웹 컨소시엄(W3C)에 의해 표준이 행해지고 IBM, 로터스 등도 자사 제품에서의 대응을 표명하고 있다. 한편, SOAP 메시지의 생성 엔진은 ‘SOAP 프럭시’, 해석 엔진은 ‘SOAP 리스너, SOAP에 의해 외부로부터 이용 가능한 부품화된 웹 기반의 응용 프로그램은 ‘웹 서비스’라고 불린다. 인터넷상에서 각 회사가 제공하고 있는 웹 서비스를 모아 누구라도 검색, 조회할 수 있도록 하는 것이 UDDI이다.

출처 : http://enc.daum.net/dic100/contents.do?query1=15XXXX3351

 

전송 방식 (Transport Method)

SOAP는 인터넷 어플리케이션 계층에 있는 프로토콜을 전송계층의 프로토콜로 사용할 수 있게 만든다. 혹자는 이러한 프로토콜의 의도된 목적과 역할이 맞지 않는 부정이용에 대하여 비판하지만, SOAP의 지지자들은 터널링을 위한 다양한 계층(level)에서 사용되고 있는 다른 프로토콜들과 비슷하다고 말하고 있다. SMTP와 HTTP에서 어플리케이션 계층 프로토콜로 트랜스포트 계층의 역할을 대신하는 것이 SOAP는 올바른 이용이라 할 수 있으나, HTTP는 오늘날 인터넷 인프라와 매우 잘 동작하여 더 폭넓은 지원을 가능하게 한다. 특히나, HTTP는 방화벽이 작동하는 네트워크 안에서도 문제 없이 작동한다. SOAP는 HTTPS(어플리케이션 계층에서는 HTTP와 동일하나 트랜스포트 계층 아래에서는 암호화됨)에서도 간략하게 또는 상호적으로 사용된다.

이는 WS-I방식으로 Basic Profile 1.1에서 서술된 것과 같이 웹서비스의 보안을 제공하고 있다. 이 점은, GIOP/IIOP 혹은 DCOM등과 같은 방화벽에서 쉽게 필터링 당하는 여타의 배포 프로토콜등과의 비교 우위를 점하고 있다. XML은 대다수 회사들과 오픈 소스 개발 진영 쪽의 노력에 힘입어 광범위하게 사용되는 메시지 포맷으로써 표준으로 선택되었다. 추가적으로, 광범위하게 무료로 사용한 툴들이 상당하게 포진하고 있는 점은 SOAP-기반 구현으로 옮겨가기 쉽게 하였다. XML의 문법이 다소 긴 점은 장단점을 모두 가질 수 있다고 할 수 있다. 사람이 쉽게 읽을 수 있는 반면, 불필요한 정보 때문에, 처리속도가 늦어질 수 있다. 예를 들어, CORBA , GIOP , ICE 그리고 DCOM 같은 경우에 바이너리 메시지 포맷을 사용하므로 상대적으로 훨씬 전송량이 적다. 반면에, 하드웨어적인 장치로, XML 메시지 처리를 빠르게 할 수 있다. 바이너리 XML은 스트리밍 전송에 대한 대안으로 (속도를 높이는 수단으로) 검토되고 있는 중이다.

출처 : http://ko.wikipedia.org/wiki/SOAP



_M#]

[#M_더보기|접기|

REST - representational state transfer

<참고 자료>

확장성 생성 언어(XML) 파일로 된 웹 페이지를 읽어 원하는 정보를 수집하는 기능. 웹 페이지를 만드는 사람은 주기적으로 내용을 개정하고 사용자는 그 페이지의 URL만 알면 웹 브라우저로 읽어 정보를 얻을 수 있다. 하이퍼텍스트 전송 규약(HTTP)과 XML을 포함한 웹 기술 및 프로토콜을 사용하는 구조적 형태로서 단순 객체 접근 프로토콜(SOAP)보다 사용이 간편하고, 사이트 내용을 기술하는 RSS(RDF Site Summary)의 정보 편집 기능과 유사하다. RSS는 자원 기술 개념(RDF)을 사용한다.

출처 : http://enc.daum.net/dic100/contents.do?query1=15XXX21008

 

원리

REST의 지지자들은 웹이 몇 가지 핵심 설계 원칙의 직접적인 결과로서 확장성과 성장성을 갖게 되었다고 주장한다.

l        응용 프로그램의 상태와 기능들은 리소스들로 나뉜다.

l        모든 리소스는 하이퍼미디어 링크를 사용하는 공통 문법을 이용하여 유일한 방식으로 주소를 지정한다.

l        모든 리소스들은 클라이언트와 리소스 사이의 상태 전송을 위한 유일한 인터페이스를 공유한다. 다음과 같이 이루어져 있다.

n         잘 정의된(well-defined) 명령어들의 제약 집합.

n         콘텐츠 종류와, 코드 온 디멘드를 부분적으로 지원하는 제약 집합

l        프로토콜은 아래와 같다

n         클라이언트/서버

n         무상태(Stateless)

n         캐시 처리 가능

n         계층화

출처 : http://ko.wikipedia.org/wiki/REST

 

RDF [Resource Description Framework, RDF]

웹에 있는 자원에 관한 메타 정보를 표현하기 위한 언어. RW3C의 가장 기본적 시맨틱 웹 언어로서 웹 자원을 표현하는데 기본이 되는 제목, 저자, 최종 수정일, 저작권과 같은 웹 문서에 관한 메타 데이터를 XML을 기반으로 매우 간단하게 표현한다. 기본적으로 주어, 동사, 목적어에 해당하는 것을 URI를 써서 대상들을 문장으로 구성하거나 노드와 화살표를 써서 도식적으로 표현하기도 한다.

 

출처 : http://enc.daum.net/dic100/contents.do?query1=15XXX23287



_M#]

 

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

SOAP

SOA BPM 2009. 4. 9. 17:51

SOAP

From Wikipedia, the free encyclopedia

  (Redirected from Simple Object Access Protocol)
Jump to: navigation, search
For other uses, see Soap (disambiguation).

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built.

As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.

The SOAP architecture consists of several layers of specifications for message format, message exchange patterns (MEP), underlying transport protocol bindings, message processing models, and protocol extensibility. SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere (probably from WDDX).[citation needed]

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

WSDL(Web Services Description Language)

SOA BPM 2009. 4. 2. 11:33

Web Services Description Language

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Web Services Description Language
Image:WSDL.svg
Filename extension .wsdl
Internet media type application/wsdl+xml
Developed by World Wide Web Consortium
Contained by XML
Standard(s) 2.0 Recommendation

The Web Services Description Language (WSDL, pronounced 'wiz-dəl' or spelled out, 'W-S-D-L') is an XML-based language that provides a model for describing Web services.

 


저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

REST(Representational State Transfer)

SOA BPM 2009. 4. 1. 11:54

Representational State Transfer

From Wikipedia, the free encyclopedia

  (Redirected from REST)
Jump to: navigation, search
"REST" redirects here. For other uses, see Rest.

Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. As such, it is not strictly a method for building "web services." The terms "representational state transfer" and "REST" were introduced in 2000 in the doctoral dissertation of Roy Fielding,[1] one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification.

REST refers in the strictest sense to a collection of network architecture principles which outline how resources are defined and addressed. The term is often used more loosely to describe any simple interface which transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies. These two meanings can conflict as well as overlap. It is possible to design a software system in accordance with Fielding's REST architectural style without using HTTP and without interacting with the World Wide Web.[2] It is also possible to design simple XML+HTTP interfaces which do not conform to REST principles, and instead follow a model of remote procedure call. The difference between the uses of the term "REST" therefore causes some confusion in technical discussions.

Systems which follow Fielding's REST principles are often referred to as "RESTful".


저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

BPEL(Business Process Execution Language)

SOA BPM 2009. 4. 1. 11:37

Business Process Execution Language

From Wikipedia, the free encyclopedia

  (Redirected from BPEL)
Jump to: navigation, search

Business Process Execution Language (BPEL), short for Web Services Business Process Execution Language (WS-BPEL) is an executable language for specifying interactions with Web Services.[1] Processes in Business Process Execution Language export and import information by using Web Service interfaces exclusively.

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

MRP(Material Requirements Planning)

SOA BPM 2009. 4. 1. 10:45

Material Requirements Planning

From Wikipedia, the free encyclopedia

Material Requirements Planning (MRP) is a software based production planning and inventory control system used to manage manufacturing processes. Although it is not common nowadays, it is possible to conduct MRP by hand as well.

An MRP system is intended to simultaneously meet three objectives:

  • Ensure materials and products are available for production and delivery to customers.
  • Maintain the lowest possible level of inventory.
  • Plan manufacturing activities, delivery schedules and purchasing activities.
저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,
  • «
  • 1
  • 2
  • 3
  • »

카테고리

  • Inforamtion Technology (281)
    • DESIGN PATTERN (33)
      • 실용주의 디자인패턴 (29)
    • SOFTWARE ENGINEERING (21)
      • Art Of Readable Code (12)
      • Object Oriented Programming (6)
      • TDD (2)
    • FRAMEWORK (22)
      • Spring.net (2)
      • LightSwitch (20)
    • PROGRAMING (58)
      • C# (20)
      • .NET (6)
      • HTML5 (7)
      • ASP.NET (9)
      • SILVERLIGHT (7)
      • Ruby On Rails (6)
    • PROJECT MANAGEMENT (10)
      • SW Version Management (7)
      • Schedulring Management (1)
    • BOOKS (18)
    • MOBILE APP (1)
      • SENCHA TOUCH (1)
    • SECURITY (5)
    • MES (1)
    • B2B (14)
      • WEBMETHODS (4)
    • ERP (53)
      • SAP/R/3 (51)
    • ABOUT TOOLS (2)
    • FUNDAMENT CONCEPT (21)
    • SOA BPM (22)
    • PORTFOLIO (0)

태그목록

  • 동시성
  • 병렬
  • 프로그래밍

최근에 받은 트랙백

글 보관함

링크

파란실버라이트

블로그 이미지

To remember the time when I started learning Silver Light!

LATEST FROM OUR BLOG

RSS 구독하기

LATEST COMMENTS

BLOG VISITORS

  • Total :
  • Today :
  • Yesterday :

Copyright © 2015 Socialdev. All Rights Reserved.

티스토리툴바