1. AEM Core Technology의 구성 Apache Sling OSGI Felix application runtime JCR content repository 2. OSGI Felix application runtime OSGI 주요 콘솔은 아래와 같다. 콘솔 콘솔 콘솔 모든 bundle은 서로 간의 dependency를 가지며, apache felix가 가장 root인 (id=0) bundle이다. 해당 콘솔에서는 bundle간의 의존 관계를 파악할 수 있다. 하위의 bundle이 죽게 되면 거기에 의존하고 있는 상위의 bundle도 malfunction하게 된다. 이는 트러블슈팅 시에 중요한 개념이다. 3. 데이터 저장 방식 데이터 저장 시 현대기아는 tarMK 방식 사용 (서버의 repository 폴더), Cluster 방식에서는 mmongoDB, AWS s3, Azure blob storage등을 활용할 수도 있다. 4. Reusability AEM에는 Re…

1. AEM Core Technology의 구성 Apache Sling OSGI Felix application runtime JCR content repository 2. OSGI Felix application runtime OSGI 주요 콘솔은 아래와 같다. 콘솔 콘솔 콘솔 모든 bundle은 서로 간의 dependency를 가지며, apache felix가 가장 root인 (id=0) bundle이다. 해당 콘솔에서는 bundle간의 의존 관계를 파악할 수 있다. 하위의 bundle이 죽게 되면 거기에 의존하고 있는 상위의 bundle도 malfunction하게 된다. 이는 트러블슈팅 시에 중요한 개념이다. 3. 데이터 저장 방식 데이터 저장 시 현대기아는 tarMK 방식 사용 (서버의 repository 폴더), Cluster 방식에서는 mmongoDB, AWS s3, Azure blob storage등을 활용할 수도 있다. 4. Reusability AEM에는 Re…

1. HTTP 일반 헤더 헤더에는 http 전송을 위해 필요한 모든 부가 정보를 담는다. 메시지 바디 내용, 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등.. RFC2616에서 RFC723x로 변화 entity 대신 representation으로 개념이 바뀜 표현 = 표현 메타 데이터 + 표현 데이터 표현 표현 헤더는, request, response 모두 사용한다. Content-Type test/html; charset=UTF-8 application/json image/png Content-Encoding 표현 데이터를 압축하기 위해 주로 사용 gzip, deflate, identity Content-Language 자연 언어 표현 ko, en, en-US Content-Length 바이트 단위 Transfer-Encoding 을 사용하면 Content-Length 사용하면 안됨 콘텐츠 협상(contents negotiation) 협상 헤더는 클라언트…

1. HTTP 메소드 API URI에 대한 고민 API URI를 고민할 떄 가장 중요한 기준은 ‘리소스의 식별’ 이다. ex) 회원을 조회한다고 할 때 ‘회원’ 자체가 리소스이다. 따라서 URI에 ‘회원’을 매핑 해주어야 한다. 리소스는 ‘복수형’으로 사용한다. ex) members(O), member(x) 리소스와 행위를 구분한다. 행위는 http 메소드를 통해 구분한다. HTTP 메소드 : GET, POST HTTP 메소드 종류 GET : 리소스 조회 POST: 요청 데이터 처리, 등록에 사용 PUT : 리소스를 대체 DELETE : 리소스 삭제 PATCH : 리소스 부분 변경 GET 리소스 조회 서버에 전달하고자 하는 데이터는 query param을 통해 전달 GET에서도 body를 지원하긴 하지만 지원하지 않는 서버도 존재하여 권장되지 않음 POST 데이터 등록, 요청 데이터를 통한 프로세스 처리 메시지 body를 통해 서버로 데이터 전달 다른 메소드로 처리하기 애매할 경…

1. 인터넷 네트워크 어떻게 이렇게 복잡한 ‘인터넷’이라는 경로를 거쳐 컴퓨터는 통신하게 되는가? → IP(internet protocol)을 통해서 가능하다. IP 지정한 IP 주소로 ‘packet’이라는 통신 단위로 데이터를 전달한다. 패킷에는 출발지/목적지에 대한 정보가 들어있어서, 클라이언트 ↔ 서버 간에 통신이 가능해진다. Client → Sever Server → Client IP 프로토콜의 한계 그러나 IP프로토콜 만으로는 출발지 ↔ 목적지 사이의 원활하고 안정적인 통신이 불가능하다. 아래의 이유 때문에. 1) 비연결성 패킷을 받을 수 없거나 서비스 불능 상태여도 패킷을 전송한다. 2) 비신뢰성 중간에 패킷이 소실 되는 것에 대한 대책이 없다. 패킷이 요청 순서대로 간다는 것을 보장할 수 없다. 3) 프로그램 구분 같은 IP를 사용하는 서버에서 통신하려는 애플리케이션이 2개 이상인 경우 구분할 수 없다. TCP 이러한 IP 프로토콜의 한계를 TCP 프로토콜이 …

OAuth는 어떤 시스템에서 그 시스템의 사용자들이 Google, Facebook, KaKao talk과 같은 서비스에 직접 연결하지 않고도 시스템을 통해 각 서비스(Google,Facebook등) 의 기능을 이용하고 싶은 욕구로 인해 등장한 개념이다. 이 때 시스템이 사용자들의 서비스 계정정보를 모두 가지고 있다면 해당 문제가 쉽게 해결 되겠지만, 그것은 보안 상 매우 취약한 방법이다. 왜냐하면, 사용자 입장에서는 처음 보는 시스템에 자신의 카카오 계정정보를 맡겨야 되는 것이고, 시스템 입장에서도 사용자들의 카카오 계정정보를 가지고 있는 것 자체가 부담이다. 서비스 입장에서도 자신들의 사용자 정보를 신뢰할 수 없는 ‘시스템’에게 맡기는 것은 말도 안된다. 그래서 우리에겐 OAuth가 필요하다.​ OAuth에는 앞서 말한 것처럼 사용자, 시스템, 서비스 3가지의 주체가 있고, OAuth에서는 이를 각각 Resource owner(사용자), Client(시스템), Resource …

AEM 을 소개함에 있어 해당 과정은 Udemy의 https://www.udemy.com/course/adobe-experience-manager-63 과정을 영어가 어려운 사람들을 위해 한국어로 정리하는 데 목적이 있음을 밝힌다. AEM 관련해서 체계적으로 정리해둔 블로그를 찾지 못했기 때문이기도 하다. AEM 소개 AEM은 ‘Adobe Experience Manager’ 의 약어이며, 어도비 사에서 만든 Java 기반의 CMS 솔루션이다. AEM은 상용 웹 사이트를 만드는 데 많이 사용되며 웹 사이트의 콘텐츠와 asset 들을 관리하기에 용이하며 배포까지 지원한다. 웹사이트와 CMS 웹 사이트에는 3가지 종류가 있다. Static 웹 사이트 : 정적 리소스로만 이루어진 웹 사이트이다. Dynamic 웹 사이트 : 클라이언트/서버의 스크립트를 통해 동적으로 웹 사이트의 콘텐츠를 관리하는 웹 사이트이다. CMS template을 생성할 수 있다 재사용 가능한 Component를 생…

Http Status Code 제어 REST API를 통해 User를 생성하는 API를 만드는 상황을 가정해보자. 좀 더 나은 API 설계를 고려한다면 단순히 User를 생성만 하는 것에서 그칠 것이 아니라 요청자에게 response로 결과 데이터를 반환해주어야 할 것이다. 가령 사용자에게 요청 값을 반환해 주기 위해 ServletUriComponentsBuilder 라는 클래스를 사용할 수 있다. 이렇게 하면 클라이언트는 Header로부터 200을 받는 것이 아니라 201 created 값을 반환받을 수 있게 되며 header의 Key값 중 location값에서 POST의 URI value를 알 수 있다. 여기선 http://localhost:8080/users/10 이 될 것이다. 이렇듯 200 OK로만 보내는 것이 아니라 CRUD에 따라, 그리고 여러가지 상황에 따라 서로 다른 HTTP status code값으로 응답해주는 것이 좋고, location값을 반환 해 줌에 따라 …

REST와 대비하여 자주 언급되는 SOAP이라는 개념이 있다. SOAP이란 무엇인가? Simple Object Access Protocol의 약자로서 http,https,smtp를 이용하여 XML메시지로 통신을 가능하게 해주는 프로토콜을 말한다. 아래 그림과 같이 XML로 request를 보내고 XML로 response를 받는다. 그리고 그 XML 메시지의 구조는 아래와 같이 Envelope, Header, Body의 세 부분(+Fault 부분 option)으로 이루어져 있다. 실제 SOAP의 메시지 구조를 살펴보면 아래와 같다. 전달하고자 하는 내용에 비해 부가적인 태그나 설정 관련 텍스트가 많아서 통신 시 불필요한 오버헤드가 발생할 뿐만 아니라 개발 하기에 까다롭기도 하다. SOAP vs REST SOAP과 REST의 차이점을 아주 잘 보여주는 표가 있어서 가져와보았다. SOAP와 REST의 공통점이라고 한다면 HTTP,HTTPS를 통해 데이터를 통신한다는 점이지만 …

REST에 대해서 웹 문서들을 살펴보면 여러가지 표현들로 설명하고 있는데, 그것을 조합해서 내가 이해하기 쉽게 정의하자면 아래와 같다. “REST API란 HTTP Method를 사용하여 HTTP URI 형태로 명시된 리소스를 처리(CRUD) 하도록 설계된 클라이언트와 서버 간의 통신 방식이다” 클라이언트가 GET, POST, PUT, DELETE 등의 HTTP 메소드를 통해 URI로 서버에 요청하게 되면 서버는 해당되는 리소스에 대한 CRUD를 처리하고 클라이언트에 JSON 데이터를 반환한다. REST API의 구성 요소 1. Resource : REST에서는 resource의 정보를 표현할 수 있어야 하며 이를 위해 URI를 사용한다. 2. Method : resource에 대한 행위를 표현하며, HTTP의 GET(조회), POST(추가), PUT(수정), DELETE(삭제) 메소드를 사용한다. 3. Representaion : REST에서 representation(표현)이…