Q1. API란 무엇인가?
API란?(Applicaton Programming Interface)
API는 정의 및 프로토콜 집합을 사용하여 두 소프트 웨어 구성 요소가 서로 통신 할 수 있게 하는 메커니즘이다. 예를 들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있습니다. 휴대폰의 날씨 앱은 API를 통해 이 시스템과 “대화”하고 휴대폰에 매일 최신 날씨 정보를 표시한다.
API는 어떻게 작동하나요?
API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명된다. 요청을 보내는 애플리케이션을 클라이언트라 하고 응답를 보내는 애플리케이션을 서버라고 한다. 다라서 날씨 예에서 기상청의 날씨 데이터베이스는 서버이고 모바일 앱은 클라이언트이다.
API유형은 어떤게 있을까?
1) private API
private API는 내부 API로, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행한다. 따라서 제 3자에게 노출되지 않는다.
2) publice API
publice API는 개방형 API로, 모두에게 공개된다. 누구나 제한 없이 API를 사용할 수 있는 게 특징이다.
3) parthner API
parthner API는 기업이 데이터 공유에 동의하는 특정인들만 사용할 수 있다. 비즈니스 관계에서 사용되는 편이며, 종종 파트너회사 간에 소프트웨어를 통합하기 위해 사용된다.
REST API VS SOAP API
API의 구조를 이야기할 때, 가장 대표적인 두 가지 방식으로 SOAP API와 REST API를 흔히 말한다. “SOAP REST 차이”는 사실 두 가지 방식은 비슷하기는 하지만 본질적으로는 서로 다른 기술이며 세부적인 수준가지 비교하기 쉽지 않다.
REST API
REST(Repersentational State Reansfer)는 네트워크를 통해서 컴퓨터들끼리 통신할 수 있게 해주는 아키텍처 스타일 이다. REST API는 인터넷 식별자(URI)와 HTTP 프토토콜을 기반으로 한다. REST는 HTTP 프토토콜 덕분에 ‘단순함’이 핵심이라고 할 수 있다. 데이터 포맷으로는 브라우저 간 호환성이 좋은 JSON을 사용한다.
REST는 웹에 최적화되어 있고, 데이터 포맷이 JSON이기 때문에 브라우저들 간에 호환성이 좋다. 또한, 그 성능과 확장성이 뛰어난 것으로도 알려져 있다. 하지만 다른 기술들과 마찬가지로 그 자체의 기능이 정지되거나 여러분의 앱을 먹통으로 만들 수도 있다. 그래서 REST로는 풀지 못하는 문제들을 해결하기 위해서 그래프QL과 같은 언어가 생겨났다.
SOAP API
SOAP(SIMPLE Object Access Protocol)는 그 자체로 프로토콜이면, 보안이나 메시지 전송 들에 있어서 REST보다 더 많은 표준들이 정해져 있기 때문에 조금 더 복잡하다. 이러한 표준들로 인해서 오버헤드가 많기는 하지만, 보안 , 트랜잭션, ACID(원자성, 일관성, 고립성, 지속성)을 준수해야 하는 보다 종합적인 기능이 필요한 조직에게는 적합한 방식이 될 수 있다. 굳이 비교를 하자면, SOAP는 웹 서비스 시나리오에 적용하기에는 그다지 좋지 않기 때문에 기업용 애플리케이션들을 작업하는데 더 이상적이라고 말할 수 있다.
SOAP는 보안 수준이 엄격하다. SOAP에서는 SSL도 지원하고 WS-Seacurity라는 자체 표준의 보안 기능도 가지고 있다. 따라서 은행용 모바일 앱처럼 보안 수준이 높아야 하거나, 신뢰할 수 있는 메시징 앱, 또는 ACID를 준수해야 하는 경우라면 SOAP 방식이 더욱 선호 된다.
Q2. Client와 Sever란 무엇인가?
Client
서버에 서비스 요청을 하는 곳 즉 서버로부터 정보를 제공 받는 브라우저를 클라이언트라고 한다.
정확하게 사용자가 사용하는 웹 브라우저를 의미하지만, 사용자가 사용하는 기기 또는 사용자를 클라이언트라고 부르기도 한다.
Server
클라이언트에게서 서비스 요청을 받고 요청을 수행한 뒤 응답을 하는 곳을 서버라 한다.
서버와 클라이언트
서버는 클라이언트의 요청을 언제든 받아서 서비스를 해야 하므로 항상 네트워크 전체를 모니터링 해야 하며 어떤 컴퓨터든 서버가 될 수 있지만 주로 고성능 컴퓨터를 서버로 사용한다.
한 대의 서버에 여러 대의 클라이언트가 접속하여 서비스를 받는 방식을 서버/클라이언트 구조라고 한다.
웹 서버와 웹 브라우저
웹 서버는 각종 정보를 담은 페이지를 클라이언트에 제공한다.
이 클라이언트들은 웹 브라우저라고 불리는 전용 클라이언트 어플리케이션으로 웹 브라우저가 페이지를 서버에 요청(request)하면 서버가 응답(response)하여 페이지를 받아 보여주는 방식으로 구성되어있다.
웹 서버에 대한 수요가 점점 증가하며 웹 서비스는 더 다양한 기능을 제공하기 위해 웹페이지에 여러 기능을 담기 시작했으며 이렇게 웹 페이지를 매개로 작동하는 응용프로그램들을 웹 서버와 구분하여 WAS(웹 어플리케이션 서버)부른다.
Q3. WAS란 무엇인가? Web Server와 차이점은 무엇인가?
WAS
- 동적인 컨텐츠 제공
- 데이터베이스 조회나 다양한 로직 처리
Web Server
- 정적인 컨텐츠 제공
- 클라이언트로부터 http요청을 받아드림
Q4. HTTP 프로토콜이란 무엇인가?
정의
Http(Hypertext Transfer Protocol) 프로토콜이란 상호간에 정의한 규칙의 의미 하며 특정 기기 간에 데이터를 주고받기
위해 정의된다.
= ex) “내가 이렇게 보내면 너는 이렇게 받아”
특히! 웹에서는 브라우저와 서버 간에 데이터를 주고받기 위한 방식으로 사용
특징
1. 상태가 없는(stateless) 프로토콜이다.
[데이터를 주고 받기 위한 각각의 데이터 요청이 서로 독립적으로 관리가 된다. 즉 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다.-> 이로 인해 서버는 세션과 같은 별도의 추가 정보를 관리하지 않아도 되고, 다수의 요청 처리 및 서버의 부하를 줄일 수 있는 성능 상의 이점이 생긴다.]
2. 일반적으로 TCP/IP 통신 위에서 동작하며 기본 포트는 80번이다.
HTTP 프로토콜 작동 원리
데이터를 주고 받기 위해서는 요청(Request)와 응답(Response)을 주고받아야 한다.
즉 Client(요청을 보내는 쪽으로, 웹의 관점에서 브라우저 의미)와 Server(요청을 받는 쪽으로 데이터를 보내주는 원격지의 컴퓨터 의미)의 상호 작용이 필요하다.
이때 서버에 자원을 요청하기 위해 입력하는 영문 주소인 URL이 필요하다.
URL 구조
HTTP 요청 메서드
위의 URL을 통해 서버에 특정데이터를 요청할 수 있는데 이때 요청 데이터에 특정 동작을 수행하고 싶으면 요청 메서드를 이용하게 된다.
- 종류
GET : 존재하는 자원에 대한 요청
POST : 새로운 자원을 생성
PUT : 존재하는 자원에 대한 변경
DELETE : 존재하는 자원에 대한 삭제
->이와 같이 데이터에 대한 조회, 생성, 변경, 삭제 동작을 HTTP 요청 메서드로 정의하며 때에 따라서는 POST 메서드로 PUT, DELETE의 동작도 수행할 수 있다.
- 기타
HEAD : 서버 헤더 정보를 획득. GET과 비슷하나 Response Body를 반환하지 않음
OPTIONS : 서버 옵션들을 확인하기 위한 요청. CORS에서 사용
HTTP 상태 코드
서버에서 설정해주는 응답(Response) 정보
2xx - 성공
- 200 : GET 요청에 대한 성공
- 204 : No Content. 성공했으나 응답 본문에 데이터가 없음
- 206 : Partial Conent. 성공했으나 일부 범위의 데이터만 반환
- 205 : Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고
- 206 : Partial Conent. 성공했으나 일부 범위의 데이터만 반환
- 204 : No Content. 성공했으나 응답 본문에 데이터가 없음
- 205 : Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고
-> 200번대의 상태 코드는 대부분 성공을 의미
3xx - 리다이렉션
- 301 : Moved Permanently, 요청한 자원이 새 URL에 존재
- 303 : See Other, 요청한 자원이 임시 주소에 존재
- 304 : Not Modified, 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고. ETag와 같은 정보를 활용하여 변경 여부를 확인
-> 300번대의 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우
4xx - 클라이언트 에러
- 400 : Bad Request, 잘못된 요청
- 401 : Unauthorized, 권한 없이 요청. Authorization 헤더가 잘못된 경우
- 403 : Forbidden, 서버에서 해당 자원에 대해 접근 금지
- 404: 요청한 자원이 서버에 존재하지 않음
- 405 : Method Not Allowed, 허용되지 않은 요청 메서드
- 409 : Conflict, 최신 자원이 아닌데 업데이트하는 경우. ex) 파일 업로드 시 버전 충돌
-> 400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우로 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우 발생한다.
5xx - 서버 에러
- 501 : Not Implemented, 요청한 동작에 대해 서버가 수행할 수 없는 경우
- 503 : Service Unavailable, 서버가 과부하 또는 유지 보수로 내려간 경우
-> 500번대 상태 코드는 서버 쪽에서 오류가 난 경우
정리
Q5. Restful API는 무엇인가?
REST API란
REST 기반으로 서비스 API를 구현한 것
REST (Representational State Transfer)
자원을 이름으로 구분하여 자원의 상태를 주고받는 모든 것
URI를 통해 자원을 명시하고 Methed를 동해 자원에 대한 CRUD를 적용한다.
구성요소
자원(Resource)
- 표현방법 : HTTP URI
- REST API의 수행 대상으로서 JSON, XML 문서이거나 혹은 이미지 파일, 비디오 파일
- 이러한 자원을 URI(Uniform Resource Identifier, 통합 자원 식별자로) 정의하여 사용한다.
행위(Verb)
- 표현방법 : HTTP Method
- 리소스(Resource)에 대한 행위에 대한 정의
메시지(Representations)
- HTTP Message Pay Load
- 자원이 어떠한 것인지 명확히 하기 위해 자원의 형태를 정의
- 자원이 JSON파일이면 REST API의 헤더(Header) 부분에 "Content-Type:application/json"을 추가
장점
- 유니폼 인터페이스로 되어있어서 HTTP표준 프로토콜을 따르는 모든 플렛폼에서 사용가능해 특정 언어에 종속되지 않는다.
- 여러 종류의 파일들을 일관된 형태로 처리한다.
- 자체표현구조 : 동사+명사로 이루어져 rest api를 읽는것만으로 명확하게 의도를 파악할 수 있게된다.
- http 인프라를 그대로 사용하기때문에 별도의 인프라도 필요치 않다. 캐싱기능등의 http 기능을 그대로 사용할 수 있다.
- 무상태성을 가지므로 상태정보들이 저장되지 않고 단순히 요청만을 처리하기에 구현이 단순하고 자유도가 높다.
- 서버와 클라이언트 간의 역할이 명확하게 분리되어있다.
단점
- 사용하는 메소드가 4가지뿐이다
🔑 @Setter를 사용하지 않고 @Builder를 사용하는 이유
개요
프로그래밍 개발을 진행하다가 보면, 생성자를 통해 객체를 많이 생산하게 된다.
객체가 가지고 있는 인자들이 많을 경우 그 인자들이 어떠한 값인지 헷갈릴 경우가 있다. 또한, 생성자 호출을 위해서 설정하길 원하지 않는 매개변수의 값까지 지정해줘야 하는 불편함이 있다.
즉, 생성자를 빌더패턴으로 생성하지 않았을 경우 코드를 읽을 때 각 값의 의미가 무엇인지 헷갈릴 수 있고, 매개변수가 몇개인지 세어보며 항상 확인해야 하면, 타입이 같은 매개변수가 연속으로 있으면 버그 발생 가능성이 높어지며, 실수로 매개변수의 순서가 바뀌더라도 컴파일러가 해당 에러를 잡지 못하여 런타임 에러로 이어지게 될 수 있다.
Builder 패턴이란?
빌더 패턴이란 복합 객체의 생성 과정과 표현 방벙을 분리하여 동일한 생성 정차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴이다. 생성자 인자로 너무 많은 인자가 넘겨지는 경우 어떠한 인자가 어떠한 겂을 나타내는지 확인하기 힘들다.
또 어떠한 인스턴스의 경우에는 특정 인자만으로 생성해야 하는 경우가 발생한다. 특정 인자에 해당하는 값을 nulll로 전달해줘야 하는데, 이는 코드의 가독성 측면에서 매우 좋지 않다는 것을 알 수 있다.
Lombok을 이용하여 생성.
Builder 패턴을 적용할 클래스.
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Builder(builderMethodName = "HeroBuilder")
@ToString
public class Hero {
private final Profession profession;
private final String name;
private final HairType hairType;
private final HairColor hairColor;
private final Armor armor;
private final Weapon weapon;
public static HeroBuilder builder(String name) {
if(name == null) {
throw new IllegalArgumentException("필수 파라미터 누락");
}
return HeroCheckListBuilder().name(name);
}
}
Builder 패턴을 이용하여 생성자 생성.
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Builder(builderMethodName = "HeroBuilder")
@ToString
public class Hero {
private final Profession profession;
private final String name;
private final HairType hairType;
private final HairColor hairColor;
private final Armor armor;
private final Weapon weapon;
public static HeroBuilder builder(String name) {
if(name == null) {
throw new IllegalArgumentException("필수 파라미터 누락");
}
return HeroCheckListBuilder().name(name);
}
}
- @AllArgsConstructor(access = AccessLevel.PRIVATE)
- @Builder 어노테이션을 선언하면 전체 인자를 갖는 생성자를 자동으로 만듭니다.
- @AllArgsConstructor는 전체 인자를 갖는 생성자를 만드는데, 접근자를 private으로 만들어서 외부에서 접근할 수 없도록 만듭니다.
- @Builder
- 위에서 설명한 듯이 Builder 패턴을 자동으로 생성해주는데, builderMethodName에 들어간 이름으로 빌더 메소드를 생성해줍니다.
- 클래스 내부 builder 메소드
- 필수로 들어가야 할 필드들을 검증하기 위해 만들어졌습니다.
- 꼭 name이 아니더라도 해당 클래스를 객체로 생성할 때 필수적인 필드가 있다면 활용할 수 있습니다.
- PK를 보통 지정합니다.
Builder 패턴의 장점.
- 필요한 데이터만 설정할 수 있음.
- 유연성을 확보할 수 있음.
- 가독성을 높일 수 있음.
- 불변성을 확보할 수 있음.
🔑 DTO(Data Transfer Object)를 사용하는 이유
- Entitiy클래스와 거의 유사한 형태임에도 DTO 클래스를 추가로 생성하는 이유는 Entity 클래스가 데이터베이스와 맞닿은 핵심 클래스이기 때문이다.
- Entity 클래스를 기준으로 테이블이 생성되고 스키마가 변경되는데, 화면 변경과 같은 사소한 기능 변경을 위해 테이블과 연결된 Entity 클래스를 변경하는 것이 너무나 큰 변경이 되는 것이다,
- 다양한 비즈니스 로직과 요구사항에 대해 유연라게 대응할 수 있다.
- 파라미터로 엔티티 자체를 받게 되면 엔티티에서 정해진 포맷에 맞춰 개발을 해야한다. 하지만 DTO는 각 비즈니스 로직에 맞춘 필드들만 생성함으로써 DTO를 보면 어떤 값들이 매칭되는지 쉽게 파악할 수 있고, 만약 API 설계 상황에서 필드에 다른 이름을 부여하거나 하는 상활에서도 유연하게 대처할 수 있다.
- Controller와 Serivice 사이에서 강한 의존을 방지하기 위해서 DTO를 사용한다.
- Service가 받고 싶은 파라미터가 Controller에게 종속적이게 되면 Service가 Controller 패키지에게 의존하게 된다. 따라서 이를 방지하기 위해서라도 Service가 원하는 포맷에 맞춰 Controller딴에서 DTO를 통해 그 포맷을 맞춰준다.
🔑 GIT이란?
GIT을 사용하면 하나의 프로젝트를 여러 명 이서 효과적으로 관리하면 협업 할 수 있다.
깃을 사용하여 개발을 하면 병렬적으로 동시에 작업을 진행할 수 있어서 개발 속도가 매우 빠르게 된다. 또한 여러 명의 작업 내용을 효과적으로 관리할 수 있다.
깃의 장점
- 분산적인 개발: 깃(git)을 사용하는 전체 개발 내역을 각 개발자의 로컬 컴퓨터로 복사 할 수 있다. 나중에 서로 수정 내역을 합칠(Merge) 수도 있다.
- 효율적인 개발 : 깃(git)은 일반적인 다른 버전 관리 시스템보다 성능이 뛰어나며 변경이력이 많더라도 변경된 내용만 처리한다는 점에서 메모리적인 효율성 또한 뛰어나다
- 유연한 개발: 깃(Git)은 브랜치(Banch)를 이용하여 분기점을 만들 수 있다. 하나의 프로젝트에서 여러가지 기능을 나누어 함께 진행 가능하다.
- 변경 이력보장 : 작업되는 모든 내역(Commit)들은 모두 별도의 영역에서 관리되어 안정성이 뛰어나다.
🔑 Q4. Amazon S3에 대해서
💡 Amazon Simple Storage Service(Amazon S3)는 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스이다.
1️⃣AWS S3 특징
- HTTPS 프로토콜을 사용하여 SSL로 암호화된 엔드포인트를 통해 데이터를 안전하게 업로드/다운로드 가능
- S3의 버킷은 무한대의 객체를 저장할 수 있으므로 스토리지의 요구를 미리 추정하여 관리할 필요가 없어확장/축소에 신경쓰지 않아도 된다.
- 제공하는단순한 웹 서비스 인터페이스를 사용하여 웹에서언제 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있습니다.
2️⃣AWS S3 기본 개념
- 객체(Object)
- S3에데이터가 저장되는 기본 단위로써파일과 메타데이터로 이루어져있다. 객체 하나의 크기는1Byte부터 5TB까지 허용되며메타데이터는 MIME 형식으로파일 확장자를 통해 자동으로 설정되며 사용자 임의로도 지정 가능하다.
- 버킷(Bucket)
- S3에서 생성할 수 있는최상위 디렉토리의 개념으로이름은 S3 리전 중에서 유일해야 한다.계정별로 100개까지 생성 가능하며 버킷에 저장할 수 있는 객체수와 용량은 무제한이다.
- 표준스토리지
- S3 서비스 수준 계약으로 객체에 대해99%의 내구성을 보장하며99%의 가용성을 제공한다.하지만 높은 내구성을 보장해야 하는 만큼비용이 높으므로유실되면 안되는 원본 데이터, 민감정보, 개인정보 등의중요한 데이터를 저장하는 것이 알맞다.
- RRS(Reduced Redundancy Storage)
- 표준 스토리지보다 저렴한 비용으로 데이터를 저장할 수 있다. RRS 옵션은 여러 시설 전반에 다양한디바이스에 객체를 저장하며 일반 디스크 드라이브의 400배에 달하는 내구성을 제공하나 표준 스토리지 만큼많이 객체를 복제하지는 않으므로 원본을 복제한 데이터나 가공한 데이터(예를 들어 썸네일 같은)의 저장에 알맞다.
제공하는단순한 웹 서비스 인터페이스를 사용하여 웹에서언제 어디서나 원하는 양의 데이터를 저장하고
검색할 수 있습니다.개발자는 Amazon이자체 웹 사이트의 글로벌 네트워크 운영에 사용하는 것과 같은높은
확장성과 신뢰성을 갖춘빠르고 경제적인 데이터 스토리지 인프라에 액세스할 수 있습니다.
단독 스토리지로도 사용할 수 있으며EC2, EBS, Glacier와 같은 다른 AWS 서비스와도 함께 사용할 수 있어
클라우드 어플리케이션, 컨텐츠 배포, 백업 및 아카이빙, 재해 복구 및 빅데이터 분석을 포함한 다양한 사례에
알맞다.S3의 버킷은 무한대의 객체를 저장할 수 있으므로 스토리지의 요구를 미리 추정하여 관리할 필요가
없어확장/축소에 신경쓰지 않아도 된다.HTTPS 프로토콜을 사용하여 SSL로 암호화된 엔드포인트를 통해
데이터를 안전하게 업로드/다운로드 할 수 있으며상주 데이터를 자동으로 암호화 하고AWS KMS를 통해 S3에서
사용자를 위해 키를 관리하게 하는 방법과고유한 키를 제공하는 방법 중에서 키 관리 방법을선택할 수 있는
기능을 제공한다.사용한 스토리지 만큼 요금이 청구되며 데이터 전송부분에서는 해당 리전 내에서는데이터
송수신은 무료(다른 AWS 리전으로는 무료가 아니다!)이고 S3에서인터넷으로 데이터를 송수신 시에도 가격이
매우 저렴하다. 요금에 대한 부분은이곳에서 확인 할 수 있습니다.
🔑 Q5. springframework 기본동작 순서 및 구조
전체적인 실행 순서
Request -> DispatcherServlet -> HandlerMapping -> Controller -> Service -> DAO -> DB
-> DAO -> Service -> Controller -> DispatcherServlet -> ViewResolver -> View -> Response
순서 설명
1. 클라이언트가 Request 요청을 하면 DispatcherServlet이 요청을 가로챈다.
(이때 DispatcherServlet이 모든 요청이 아닌 web.xml에 <url-pattern>에 등록된 내용만 가로챔)
2. DispatcherServlet이 가로챈 요청을 HandlerMapping에게 보내 해당 요청을 처리할 수 있는 Controller를 찾는다.
3. 실제 로직 처리 (Controller -> Service -> DAO -> DB -> DAO -> Service -> Controller)
4. 로직 처리 후 ViewResolver를 통해 view 화면을 찾는다.
5. View화면을 최종 클라이언트에게 전송한다.