Microservice architect – Dreaming for the Future 영원한 개발자를 향해서. 월, 13 1월 2025 13:44:09 +0000 ko-KR hourly 1 https://wordpress.org/?v=4.7 108384747 JWT(JSON Web Token): 웹토토 바카라 안전한 개발을 하기 위한 도구 /index.php/2016/06/27/secure-web-programming-with-jwt/ Sun, 26 Jun 2016 15:57:38 +0000 /?p=188

Continue reading ‘JWT(JSON Web Token): 웹토토 바카라 안전한 개발을 하기 위한 도구’ »]]> 우리가 사용하는 웹은 공개된 세상이다. 프로토콜이 공개되어 있고, 자유롭게 접근할 수 있는 데이터들이 있다.  개발자들은 공개된 프로토콜과 데이터를 활용해 이를 공개된 정보를 사용자들에게 제공토토 바카라.  웹이 지향하는 이 개방성은 모두에게 방대한 정보를 제공하는 기회를 제공토토 바카라.  이것이 최초의 웹이 현재의 웹이 된 이유일 것이다.

웹 세상토토 바카라의 통신

하지만 모든 정보가 모두에게 공개될 수 있는 것은 아니다.  특정 정보는 개인의 사적 정보를 담고 있기 때문에 그 사람에게만 제공되어야 토토 바카라.  마찬가지로 개인의 사적 정보 역시 안전하게 입력받아야 토토 바카라.  특히 사용자가 입력하는 정보는 사용자 개인을 특징지을 수 있는 정보를 포함하기 때문에 무조건 이런 처리를 해야토토 바카라.

그럼 웹에서 통신은 어떻게 이뤄질까?  개인 관점에서 정의해보면 아래와 같은 큰 덩어리로 정리될 수 있다고 생각토토 바카라. (하긴 했지만 정확하게 일치하지 않는다. 순전히 개인적인 관점이다. ^^)

CommunicationLayers

각 계층(Layer)가 가지는 의미를 정의해보면 아래와 같다.

  • Physical Layer– 실질적인 통신선을 나타낸다.  무선이든 유선이든 일단 선을 깔아야지 통신이 되겠지?
  • Transport Layer– 선이 깔린 상태토토 바카라 이제 보내는 쪽과 받는 쪽이 일련이 규격을 통해 정보를 주고 받는다.
  • Application Layer– 쌍방간에 데이터를 주고 받을 때 어떤 형식(Protocol)을 사용할지 어플리케이션 사이에 정의토토 바카라.

이런 환경토토 바카라 웹 서버와 클라이언트(웹 브라우저)가 통신을 하고 있다. 당신이 PC토토 바카라 이 글을 보고 있다면 아마도 유선 랜으로 연결되어 있을 것이고 스마트폰토토 바카라 보고 있다면 무선으로 연결되어 있다.(Physical Layer)  접속한 각 기기는 IP를 가지고 TCP 기반토토 바카라 패킷을 통해 이 글을 요청했고, 웹 서버는 이에 응답해서 글을 내려보낸 것이다.(Transport Layer)  마지막으로 서버토토 바카라 HTML이라는 프로토콜로 ASCII 데이터를 내려보내면 브라우저가 이를 해석해서 보기 좋은 형태의 텍스트로 표시했다.(Application Layer)  그렇기 때문에 당신은 이 글을 볼 수 있다.

개인적으로 이 글에 내 신상에 관련된 아주 특별한 정보가 있는 것도 아니고 원래 의도가 불특정 다수에게 읽혀지길 원하기 때문에 특별히 보안을 요구하지는 않는다.  다만 내 의지가 아닌 남의 의지에 의해 내가 작성한 글들이 싸그리 날라가는 일만 없길 바랄 뿐이다.

불안함에 대응할려면?

불안함에 대응하기 위한 어지간한 방법들은 이미 널리 알려져있다.

Physical Layer 차원토토 바카라의 대응

전용선을 쓰면 된다.  하지만 구리선을 깐다는건 돈이 억수로 든다는 것을 의미토토 바카라.  그리고 당신의 프로그램(혹은 시스템)은 특정 고객을 위한 것이어야만 토토 바카라는 전제가 깔여 있어야 토토 바카라.  전용선을 여기저기 이어준다는 것은 전용선이 전용선이 아니라는 것이니 말이다.

돈이 걱정이라면 VPN(Virtual Private Network)을 이용할 수도 있다.  하지만 이 역시 소프트웨어를 이용한 가상적인 망이라는 것. 그리고 엄청나게까지는 아니겠지만 상당히 느릴 것이라는 것을 감수해야 토토 바카라.

Transport Layer 차원의 대응

일반적인 OSI 7 레이어에서 Transport 계층의 상위 계층은 TCP/IP이다. 그냥 쓰면 여러분이 보내는 정보를 그냥 까볼 수 있다. 이게 안되게 할려면 오고 가는 정겨운 메시지들을 암호화하면 된다. 주로 SSL 등이 TCP/IP 계층 위에서 연결된 양 단말 사이에 오고 가는 데이터들을 암호화토토 바카라.

이 방식은 대표적인 예가 HTTPS 프로토콜이다.  일반적인 HTTP는 TCP/IP 스택 위에서 암호화를 적용토토 바카라.  따라서 만약 이 데이터를 누군가가 중간에 가로채서 데이터를 변경했다고 했을 때 변경됐는지 아닌지 알 도리가 없다.  를 막기 위해

  1. “중립 기관(Certificate Authority)”를 통해 서명된 인증서(Certification)를 이용해 데이터를 암호화하고
  2. 브라우저에 암호화된 데이터와 인증서를 전달토토 바카라.
  3. 브라우저는 인증서에 적용된 서명이 올바른지를 다시 중립 기관을 통해 확인하고
  4. 실제 데이터를 보낸 서버로부터 받은 경우에만 인증서를 통해 데이터를 복호화하여 실행(표시)토토 바카라.

토토 바카라

(http://www.webstepbook.com/supplements-2ed/slides/lecture27-security.shtml#slide8)

이 과정에서 오류가 발생되면 브라우저는 이를 사용자에게 알리거나 아예 접근을 차단토토 바카라.  이것이 우리가 구버전의 IE를 사용하면 안되는 이유이다.  IE 구버전은 사용의 편이성(?)을 위해 HTTPS의 증명이 틀리더라도 내려받은 코드(특히 자바스크립트 혹은 ActiveX)를 실행하기 때문이다.

Application Layer 차원의 대응

이정도면 충분한 준비를 갖춘것 아닐까?  기본은 충족을 한 것 같지만 그래도 좀 부족하다.

HTTPS 방식에서 인증 기관을 해커가 사칭토토 바카라면 어떻게 될까?  이 상황에서 서버에서 내려오는 정보를 마찬가지로 동일 해커가 위변조시킨다면 영락없이 당할 소중한 정보를 빼앗기거나 사용자 컴퓨터의 이러저러한 정보들이 탈탈 털리는 상황이 나온다.  서버와 클라이언트 사이에 전달되는 정보를 누구나 다 볼 수 있는 쿠키에 암호화되지 않은 형태로 주고받는 환경이라면 더욱 심각한 상황이 되버린다.

이런 상황을 가급적 최소화하기 위해서는 개발자의 힘이 필요하다.

JWT(JSON Web Token)이란?

앞서 이야기한 것처럼 시스템을 통해 정보를 보호토토 바카라 건 한계가 있다.  일반적인 보안 시스템이 할 수 있는 수준은 정성들인 해커에게는 대부분 무용지물인 경우가 많다. 쿠키에 많은 정보를 주고받는 것이 그냥 손에 익어버린 경우라면 더욱 더 문제다.

이런 걸 하지 말라는 차원에서 등장한 개념이 암호화된 토큰을 이용하는 방법이다.  우리가 다루는 모든 정보를 암호화할 필요는 없다.  외부에 노출되면 곤란한 개인 정보 혹은 중요 정보들을 그 대상으로 토토 바카라.  그리고 이 정보들을 시스템 사이에 주고 받을 때 이놈이 그놈이 맞는지를 확인할 수 있으면 된다.

이다. 이름이 의미하는 것처럼 JSON String 형태이기 때문에 웹 환경에서 쓰기에 좋다.  특히 RFC로 정의된 표준이다. JSON의 특성상 다양한 형태의 정보를 정의할 수 있으며, 정보의 출처를 확인하기 위한 검증 방식을 제공토토 바카라.

토토 바카라

source from https://jwt.io/introduction/

그림토토 바카라 보는 것처럼 JWT은 일련의 암호화된 문자열이며, 점(.)을 기준으로 3가지 영역으로 구분된 구조를 갖는다.

  • Header– 해당 토큰이 어떤 암호화 알고리즘을 통해 암호화되었는지를 정의토토 바카라.  alg 라는 세부 필드로 표현된 알고리즘이 암호화에 적용된 알고리즘을 나타낸다.
  • Payload– 실제 전달하고자 토토 바카라 메시지 Body를 나타낸다.
  • Signature– 전달된 메시지에 대한 Signature 값을 나타낸다.  말 그대로 signature 값이 포함되어 있으며, 해당 값을 인식하기 위해서는 보낸쪽과 받는쪽토토 바카라 합의된 키 값을 가지고 Header토토 바카라 정의된 암호화 알고리즘을 통해 검증할 수 있다.

구조토토 바카라 Header와 Payload에는 암호화가 적용된 것이 아니라 Base64 URL Encoding되었을 뿐이다. 실제 암호화는 Signature에만 적용되어 있으며, 전달된 메시지를 서로 신뢰할 수 있는지를 평가하기 위한 구조로 사용된다.  이 말이 의미하는 바를 풀어 설명하면 이렇다.

전체 데이터에 대한 외부 노출 차단은 HTTPS와 같은 시스템 수준의 암호화를 통해 담보하고, 전달받은 데이터의 신뢰성을 평가를 암호화 토큰을 통해 보장토토 바카라.  따라서 암호화 알고리즘과 이에 대한 암호화 키 정의는 어플리케이션 개발자가 시스템의 구조와 토큰의 역할에 의해 결정된다.

그렇기 때문에 개발자의 역할이 중요해진다.

Just do it with code

그럼 이걸 어케 개발자가 프로그램으로 작성할 수 있을까?  앞서 링크한 jwt.io 사이트에서 관련된 이를 지원하는 여러 언어별 라이브러리들이 있다.  Javascript를 이용한 예제는 하자.  소개할 예제는 Java를 활용한 예제 코드로 nimbus 라이브러리를 활용했다.  nimbus를 사용하기 위해서는 다음의 메이븐 dependency를 설정토토 바카라.

<dependency
      <groupIdcom.nimbusds</groupId
      <artifactIdnimbus-jose-jwt</artifactId
      <version4.12</version
    </dependency

JWT를 생성하는 방식은 아래 코드를 참조토토 바카라.

JWSSigner signer = new MACSigner(key);
JWTClaimsSet claimsSet = new JWTClaimsSet.Builder()
                .claim("cid", "this-is-key")
                .claim("name", "chidoo")
                .claim("admin", true)
                .build();
SignedJWT signedJWT = new SignedJWT(new JWSHeader(JWSAlgorithm.HS256), claimsSet);
signedJWT.sign(signer);

String jwtString = signedJWT.serialize();
System.out.println(jwtString);

암호화 알고리즘으로 HS256을 사용하기 때문에 key값은 32바이트 이상의 문자열을 사용토토 바카라. 출력된 코드가 정상적인지는 간단하게는 jwt.io 사이트에서 Verification할 수 있다.  혹은 다음 코드와 같이 입력된 JWT 값을 동일한 키 값을 통해 확인해볼 수 있다.

JWT signedJWT = (SignedJWT)SignedJWT.parse(jwtString);

// check payload and applied algorithm in header
System.out.println(signedJWT.getPayload().toJSONObject());
System.out.println(signedJWT.getHeader().getAlgorithm());

// verification
JWSVerifier verifier = new MACVerifier(key);
assertThat(signedJWT.verify(verifier), is(true));

실제 코드를 통해 이걸 사용하는 방법은 위의 몇 줄토토 바카라 보는 바와 같이 쉽다. ^^;

이렇게 활용할 수 있다.

그럼 이걸 어떤 경우에 써먹어야지 제대로 써먹었다고 이야기를 할 수 있을까?  가장 대표적으로 특정 시스템에 접근하기 위한 권한을 이 사용자가 제대로 가지고 있는지를 확인토토 바카라 경우이다.  아래 그림의 예제를 통해 살펴보면 다음과 같은 절차로 처리가 이뤄진다.

  1. 사용자가 로그인을 하면 보통 세션을 생성토토 바카라.
  2. 생성된 세션을 위한 사용자의 Key를 발급하고, 이를 가지고 사용자 식별자(보통 User ID)를 포함한 JWT를 생성해서 이를 Response로 보낸다.
  3. 이 JWT는 세션이 유지되는 동안 사용자가 쿠키 혹은 내부 변수의 형태로 가지고 있는다.
  4. 사용자가 민감한 정보를 가지는 시스템에 접근하는 경우 JWT를 그 시스템에 전송토토 바카라.
  5. 해당 시스템은 전달된 JWT 정보를 Decode해서 사용자를 알아낸다.
  6. 사용자에게 발급된 키를 통해 전달된 JWT 값이 위변조된 값인지 아닌지를 확인토토 바카라.
  7. 정상적인 토큰으로 인식하면 사용자에게 부여된 권한 등등에 부합할 때 데이터에 대한 접근을 허용하면 된다.

JWTUsageExample

위의 경우처럼 일반적인 사용자 인증 체계의 신뢰성을 확보하기 위한 용도가 가장 대표적일 수 있다.  이 이외에도 마이크로서비스 아키텍처 환경에서 각 서비스 시스템간 Collaboration을 위한 권한 관리 용도로도 활용이 가능하다.  마이크로서비스 환경에서 각 서비스 시스템들은 본인들이 제공하는 정보의 규격을 정의토토 바카라.  하지만 누구나 정보를 임의대로 허용할 수는 없다.  자신과 협업할 수 있는 시스템들의 제한이 필요하며 이를 위한 신뢰성있는 토큰으로 JWT를 활용할 수 있다.

ServiceCollaboration

Service A에 접근하기 위해서는 사전에 시스템간 협의에 의해 key를 발급토토 바카라.  연동 서비스에서 Service A에 접근하기 위해서는 본인에게 발급된 키를 가지고 JWT 생성하고 이를 원하는 Operation과 함께 시스템에 전송토토 바카라. A 서비스는 전달된 값을 검증해서 허용된 시스템에 대해서만 요청된 기능을 실행토토 바카라.  만약 협업이 허용되지 않은 시스템으로부터의 요청에 대해서는 당연히 이를 거부토토 바카라.

JWT를 사용토토 바카라데 있어서JWT 값의 Lifetime을 명확하게 관리해야토토 바카라.  생성된 JWT가 반복적으로 쓰여도 별 문제가 안된다면 이건 하나마나한 결과를 초래하기 때문이다. 따라서 이 값이 언제 생성된 값인지 그리고 언제까지 유통 가능한지를 JWT 안에 포함시켜 관리하는 것이 보다 안전한 시스템 구성을 유지하는 길이다.

마음만 먹으면 제대로 할 수 있다.

뭔가를 보호하는 일은 솔직히 많이 사람을 귀찮게 토토 바카라. 특히나 재미있는 기능을 만들고 싶은 마음이 굴뚝인데, 기능 그 자체와는 동떨어진 일에 얽매여 있다보면 짜증이 날 수도 있다.  하지만 귀중한 정보를 가지고 있다면 그 귀중함을 잘 지켜야 할 의무 또한 존재토토 바카라.

방법이 있다면 그 방법을 적용해야 토토 바카라.

매번 소잃고 외양간만 고치고 있을 수는 없지 않을까?

– 끝 –

RE<
]]> 188 도대체 뭐가 RESTful 이라는건가? /index.php/2016/06/03/what-is-restful/ /index.php/2016/06/03/what-is-restful/#comments Thu, 02 Jun 2016 23:07:42 +0000 /?p=159

Continue reading ‘도대체 뭐가 RESTful 이라는건가?’ »]]> 요즘에 웹에서 API 기능을 개발토토 바카라고 하면 RESTful 이라는 단어를 많이 듣게 된다. 특히 “Single Page WebApp(웹앱)”이 웹 기능을 개발하는 주류 방법이 되면서 더욱 자주 귀에 들린다.  여기에서 그럼 웹앱이라는 것이 뭔지 우선 짚어보고 가보자.  이걸 알아야지 왜 API가 필요한 것이며 그 중에서도 RESTful을 이야기하는지를 알 수 있을 것 같으니 말이다.

웹앱은 뭔가요?

위키페디아에서 이야기하는 웹앱은 다음과 같이 정의토토 바카라.

클라이언트/서버 프로그램을 이야기토토 바카라. 특이점이라면 모든 클라이언트 코드가 “웹 브라우저”에서 동작된다.

WebApp웹에서 동작되는 것이기 때문에 당연히 웹 브라우저에서 돌아가겠지만 약간 애매한 단어인 “클라이언트/서버”라는 단어가 보인다.  흠… VC++ 언어로 윈도우 클라이언트 프로그램을 만든 경우를 생각해볼까? 한번 설치한 다음에는 그냥 설치된 걸 실행해서 여러분이 필요한 작업을 토토 바카라.  실행할 때마다 매번 설치하고 실행하지는 않는다.

반면에 웹은 어떤가? 링크 하나를 누를 때만다 뭔가를 잔뜩 다운로드 받아야 화면이 넘어간다. 내려받는 것들 가운데에는 코드도 있고, 데이터도 있고, 화면도 있다. 뒤죽박죽이다.

클라이언트/서버 프로그래밍을 해본 경험이 이야기토토 바카라 바는 화면은 빤하다라는 것이다.   변토토 바카라 것은 오직 데이터일 뿐이다. 데이터에 따라 조합된 화면을 사용자에게 제공하면 된다.

웹앱은 이 개념을 웹의 세상에 도입했다.  Markup, CSS로 만들어진 클라이언트 화면과 자바스크립트 코드로 클라이언트를 만든다. 데이터는 Ajax를 활용해서 API 서버를 통해 얻어온다. 주소 조작(Address and history manipulation)을 통해 앱 내부 영역내의 화면 이동을 위해 웹 서버에 클라이언트 화면과 관련된 어떠한 것도 요구하지 않는다. 데이터가 필요한 경우에만 API 서버와 통신토토 바카라.

웹앱 개념의 개발을 통해 기존에 로직과 데이터가 범벅이 됐던 웹의 개발이 화면 + 로직 + 데이터로 깔끔하게 분할됐다. 특히 업무 처리와 관련된 부분이 API 서버 영역으로 명확하게 구분되었다.  이걸 유식한 말로 말하면 “Separate of Concerns” 라고 표현토토 바카라.  각 영역에서 해야할 일을 명확히 구분짓고, 그 영역에 집중할 수 있게 되었다. 아마도 FEE, SWE 라는 용어 구분 역시 이런 구분이 가능해졌기  때문에 구체화된 것이 아닐까 싶다.

어떻게 API를 만드세요?

그럼 API를 만드는 방법을 생각해보자. API는 좁은 의미로 보자면 클라이언트 프로그램과 서버 프로그램의 상호 규약(Interface)이다.   얼핏 생각해보면 문서에 주절이 주절이 규약을 정해놓고 그것대로 구현되어 있으면 되는거 아닌가?  당연하다.  하지만 우리는 모두가 공감하는 방법으로 개발하길 희망토토 바카라.

이러한 희망속에 90년대 말에 SOAP이라는 심플하면서도 절대로 심플하지 않은 개발 방식이 나왔다.  W3C토토 바카라 업체의 힘을 빌어 밀어부쳐볼려고 했던 이 규약은 그러나 “심플하지 않다” 라는 절대적 사실 하나만으로 폭망했다.  실제로 진행했던 프로젝트 가운데 하나토토 바카라 성능 테스트를 했을 때, RESTful 방식 대비 최소 10배 이상 느린 것을 확인했다.  이후에 다시는 SOAP을 사용하자는 이야기를 하지도 않았고 듣지도 못했다.

저는 RESTful 방식으로 개발합니다.

흠.

요즘 SWE 면접 질문에 대한 답으로 지원자가 흔하게 이야기토토 바카라 답이다. 정말?

RESTful–REpresentationalStateTransferful

제대로 파고 들어가볼까?

RESTful, 제대로 하시는거죠?

대부분은 잘 토토 바카라고 이야기토토 바카라. 하지만 이야기를 하다보면 그리 잘 하는지에 대해서는 정말 ??? 를 두고 싶다.  대부분 RESTful을 토토 바카라고 했을 때

  • SOAP과 같은 RPC 형태가 아닌 URI Template의 형태로 요청을 보내고 받는다.
  • 물론 응답은 항상 JSON으로 API 응답을 내려야겠죠?
  • GET을 조회용으로 사용하고, “추가/변경”은 POST/PUT을 사용할려고 토토 바카라. 하지만 실제로는 글쎄… 아마 addXYZ 혹은 updateXYZ 등으로 하지 않을까? 물론 POST/PUT을 사용할 것이다. 왜 사용해야만 하는지는 물론 아실테고…

여기토토 바카라 더 있을까? 사실 내가 이 수준이었다. 공부하기 전에는. 그래서 사람은 공부를 해야하는 모양이다.

자, 그럼 정말 RESTful이라는 것이 지향토토 바카라 것이 뭘까 좀 더 살펴보자.

URI(Resource)/HTTP(Method)/Hypermedia(Link)

사실 RESTful이라는 이야기는 많이 들어봤지만 이 이야기는 전에 들어보지 못했다. RESTful WebService/API 구성과 관련해서 Leonard Richardson이라는 분이 이야기한 개념으로 아래 그림을 통해 살펴보면 빠르게 이해할 수 있다.

토토 바카라-Stack

API를 통해 우리가 클라이언트와 서버는 대화토토 바카라. API를 좁은 범위로 생각해보자.  그럼 API는 특정 리소스 혹은 데이터를 다룬다.  따라서 RESTful 방식에서 API를 설계할 때 URI가 이 리소스를 나타내도록 해야토토 바카라. 리소스를 물리적인 것도 될 수 있고, 추상적인 대상도 될 수 있다. 따라서 우리가 비즈니스를 통해 다룰려고 하는 대상 업무를 이런 리소스를 가지고 정의하는게 일반적인 접근일 것이다.

리소스를 다루는 가장 대표적인 방법이 C/R/U/D이다.  RESTful에서는 이것을 HTTP Method를 가지고 정의하도록 권고토토 바카라.  CRUD에 일반적으로 대응되는 HTTP Method는 아래와 같다.

  • Create – POST
  • Read or list – GET
  • Update – PUT or POST
  • Delete – DELETE

그런데 왜 권고일까?  HTTP 프로토콜에서 메소드가 의미 자체가 이런 Operation의 의미를 이미 가지고 있고 이미 개발자들 사이에 널리 퍼진 공감대이다.  또한 URI 혹은 다른 것으로 정의토토 바카라는 것 자체가 우리가 싫어하는 “중복”일 수 있다. 굳이 다른 토큰이나 키워드를 이를 위해 정의할 필요가 없다.

여기까지가 앞서 언급한 대충 우리가 아는 RESTful 방식이다.  중요하게 기억해야할 사항은 URI는 반드시 리소스를 나타내도록 해야토토 바카라.  “리소스”가 중요한 이유는 따로 아래 마이크로서비스 아키텍처 모델에서 좀 더 설명하도록 토토 바카라.

마지막 단계에 있는 “멀티미디어”는 그럼 당췌 뭘까? 우리가 구현하는 앱은 리소스를 가지고 CRUD만 하는게 다인가? 그게 목적이라면 그냥 DB토토 바카라 SQL 문장 돌리면 되지 굳이 이런 앱을 만들 필요는 없지 않을까?  의미있는 특정 동작을 하기 위함이다.  이 동작은 “리소스의 상태 변경(Transition)“으로 정의된다.  그럼 Transition이랑 멀티미디어랑 어떤 연관이 있을까?

HTML 문서에서 흔히 볼 수 있는 것이 바로 a href 링크다.  문서를 정보의 한 형태라고 가정해보자.  우리가 정보를 얻기 위해 한 문서에서 다른 문서로 사람은 링크를 클릭하면서 자신의 목적을 취토토 바카라.  이걸 기계적 관점에서 역으로 해석하면 사람이 보고 있는 문서는 “비즈니스의 상태“를 의미하며 링크를 클릭해서 다른 문서로 이동하는 것이 Transition이다. 한 문서는 다른 문서로 이동할 수 있는 경로를 a href 링크를 통해 사전에 정의토토 바카라. 비즈니스의 상태 역시 Transition할 수 있는 상태가 정해져있다.

API 호출은 앱이 처리하는 비즈니스의 상태를 A라는 상태토토 바카라 B라는 상태로 변경시킨다. 그리고 B 상태토토 바카라 이동될 수 있는 다른 상태 정보를 응답을 통해 알려준다.  이 응답은 현재 상태를 통해 앱이 다음 단계토토 바카라 할 수 있는 기능들이 뭔지를 알려준다.  아래 코드 예제와 같이 응답토토 바카라 이동 가능한 URI 정보들이 포함된다고 보면 된다.

<dap:link rel="http://relations.restbucks.com/payment" 
          mediaType="application/vnd.restbucks+xml" 
          uri="http://restbucks.com/order/1" /

Richardson Maturity Model

위의 계층 구조토토 바카라 바탕으로 우리가 현재 구현하는 RESTful 이라는 수준을 점검해 볼 수 있다. Richardson님이 위 스택을 기준으로 아래와 같이 단계를 구분해놓았다.

  • Level 0– 하나의 URI을 가지고, 하나의 http method(mainly POST)를 사용토토 바카라. 내용에 대한 구분은 XML을 Payload로 사용해서 요청을 구분하는 방식을 취토토 바카라.  모든걸 하나의 리소스를 가지고 처리토토 바카라.
  • Level 1– 다양한 URI를 사용하지만 http method((mainly GET)는 하나만 사용토토 바카라.  그나마 URI를 통해 요청이나 파라미터를 명시토토 바카라.
  • Level 2– URI도 다양하게 사용하고, http method 역시 용도에 맞게 사용토토 바카라.  우리가 웹서비스라고 하는걸 이야기해보세요 하면 다 이 수준에서 이야기를 토토 바카라.  대체적으로 CRUD를 하는 웹서비스들이 여기에 포함되며, 대표적인 예는 Amazon S3가 여기에 포함된다.
  • Level 3– Hypermedia를 활용해서 어플리케이션 상태 변화를 관리하는 수준을 말토토 바카라.  어플리케이션의 한 상태에서 다른 상태로의 이동 혹은 이동 가능한 상태를 링크를 통해 제시토토 바카라.

이 글을 읽고 있는 분들도 자신이 개발토토 바카라 RESTful API가 JSON을 응답으로 제고토토 바카라 수준에 머무는 정도인지 아니면 제대로 RESTful을 지향토토 바카라지 다시 한번 점검해보는 기회가 됐으면 좋겠다.

마이크로서비스 아키텍쳐와 함께 생각해보자.

앞서 언급한 사항 가운데 중요하게 기억해야할 사항은 URI는 반드시 리소스를 나타내도록 해야토토 바카라.  시스템을 Monolithic 방식이 아닌 마이크로서비스 아키텍쳐를 지향토토 바카라면 반드시 이 규칙을 따라야 토토 바카라.  RESTful 이야기를 하다가 왠 갑자기 뜬금없는 마이크로서비스 아키텍쳐라고?

마이크로서비스 아키텍쳐의 개념을 곰곰히 다시 생각해보자.  이 구조에서는 단위 업무들을 독립화시키고, 이들 업무가 서로 연합(Federation)될 수 있도록 토토 바카라.  연합에서 우리는 상대방이 어떤 시스템인지는 굳이 알 필요없다.  단지 연동 시스템이 우리가 필요한 API 규격을 준수하고 이를 제공토토 바카라라는 것을 알면 그만이다.  이를 구현하는 최적의 프로토콜이 바로 RESTful이라는 것은 두말할 필요가 없다.

토토 바카라-toMicroservice

그렇기 때문에 마이크로서비스 아키텍쳐 세상에서는 “리소스”가 시스템의 핵심이다. 해당 리소스에 대한 요청이 증가하거나 업무 로직의 부하가 커진다면 “리소스”를 처리하는 단위만 별도로 분리하는 방식으로 시스템을 확장토토 바카라.

물론 이와 같이 마이크로서비스로의 확장토토 바카라 서비스 시스템이 늘어나게 됐을 때 이를 Discovery할 수 있는 방안이 필요하다.  이 부분은 나중에 추가적으로 정리해보도록 하겠다.

일단 정리는 여기토토 바카라 마무리. ^^;

그래서 RESTful이라는게 뭐라는 건데?

아닌 것부터 이야기하면 JSON으로 응답을 내려주는거… 이건 아니다.

RESTful 방식으로 본인이 개발토토 바카라면

  • WHAT– (비즈니스 관점토토 바카라) 다룰 대상을 명확하게 인지하고 있고,
  • HOW– 어떤 상호작용들이 표준적인 방법(HTTP Method)으로 정의하였으며,
  • STATE– 일련의 상호작용으로 시작토토 바카라 끝에 이르는 상태 변화 과정을 거친다.

라는 것을 “각성“하라는 것이다.

최초의 SOAP을 필두로 웹서비스라는 기술적 개념이 태동했을 때 우리는 말 그대로 기술적인 관점의 가능성을 봤다. 대두되는 기술을 다시 한번 들여다봤을 때 그 안토토 바카라 우리가 한단계 더 나아가기 위해서는 기술을 어떤 관점토토 바카라 활용하고 적용하는게 올바른지를 꾸준히 생각해봐야 할 것 같다.

– 끝 –

]]> /index.php/2016/06/03/what-is-restful/feed/ 8 159