기술면접 대비 - Restful
들어가며
오늘은 Restful에 대해 정리해보고자 한다. 반복적으로 나오는 개념이고 이전에도 한 번 정리한 적이 있는 내용이기에 리마인드하며 스스로 개념에 대해 재정립해보고자 한다. 딥하게 파고들면 한 없이 어려워지는 개념인 것 같다. 반복적으로 보면서 숙달할 수 있어야겠다.
API(Application Programming Interface)
API란 무엇인가요?
API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 매커니즘입니다. 예를 들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있습니다. 휴대폰의 날씨 앱은 API를 통해 이 시스템과 "대화"하고 휴대폰에 매일 최신 날씨 정보를 표시합니다.
API는 무엇을 의미하나요?
API는 Application Programming Interface(애플리케이션 프로그래밍 인터페이스)의 줄임말입니다. API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 나타냅니다. 인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있습니다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다. API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있습니다.
출처 - AWS
즉 API란 음식점에서 손님과 요리사 사이에 주문을 받고, 주문받은 음식을 전달하는(요청사항을 처리하는) 점원과 같이 프로그램들, 웹의 경우 클라이언트와 웹 리소스가 서로 상호작용하는 것을 도와주는 매개체 로 볼 수 있다.
REST(Representational State Transfer)
API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍쳐 스타일의 일종이다.
웹에 존재하는 모든 자원에 고유한 URI(Uniform Resource Identifier)를 부여하여 자원을 명시하고, HTTP Method를 통해 자원에 대한 CRUD Operation 을 적용한다.
HTTP Method - CRUD Operation
1. Create - POST(자원 생성)
2. Read - GET(자원 정보 조회)
3. Update - PUT(자원 정보 전체 변경)
4. Update - PATCH(자원 정보 부분 변경)
5. Delete - DELETE(자원 삭제)
REST의 구성요소
자원(Resource) - URI
모든 자원은 고유한 ID를 가지고 ID는 서버에 존재하며 클라이언트는 각 자원의 상태를 조작하기 위해 요청을 보낸다. HTTP에서 이러한 자원을 구별하는 ID는 '/Movies/1'과 같은 HTTP URI이다.
행위(Verb) - Method
클라이언트는 URI를 이용해 자원을 지정하고 자원을 조작하기 위해 Method를 사용한다. HTTP 프로토콜에서는 GET, POST, PUT, DELETE 같은 Method를 제공한다.
표현(Representation)
클라이언트가 서버로 요청을 보냈을 때 서버가 응답으로 보내주는 자원의 상태를 의미한다. REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.
JSON이나 XML을 통해 데이터를 주고 받는 것이 일반적이다.
REST 아키텍쳐 스타일의 원칙
무상태(Stateless)
서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법을 나타낸다.
클라이언트는 임의의 순서로 리소스를 요청할 수 있으며 모든 요청은 무상태이거나 다른 요청과 분리된다. 이 REST API 설계 제약 조건은 서버가 매번 요청을 완전히 이해해서 이행할 수 있음을 의미한다.
계층화 시스템
서버는 계층화하여 구성할 수 있고 클라이언트는 이를 알 수 없다.
클라이언트의 요청을 이행하기 위하여 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에 실행되도록 RESTful 웹 서비스를 설계할 수 있다. 이러한 게층은 클라이언트에서 보이지 않는 상태로 유지된다.
캐시 가능성
클라이언트의 응답을 일부 저장하는 프로세스인 캐싱을 지원한다.
모든 사용자가 같은 응답을 받는 데이터는 캐시 데이터로 저장하여 응답시간을 줄일 수 있다.
온디멘트 코드(Code On Demand)
서버가 클라이언트에 코드를 전송하여 실행하게 한다.
REST API 설계 기본 규칙
1. URL는 정보를 자원을 표현해야 한다.
- resource는 동사보다는 명사를, 대문자 보다는 소문자를 사용한다.
- resource의 도큐먼트 이름으로는 단수 명사를 사용해야한다.
- resource의 컬렉션 이름으로는 복수 명사를 사용해야한다.
- resource의 스토어 이름으로는 복수 명사를 사용해야한다.
ex) GET /Member/1 → GET /members/1
2. 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.
1. URL에 HTTP Method가 들어가면 안된다.
ex) GET /members/delete/1 → DELETE /members/1
2. URL에 행위에 대한 동사 표현이 들어가면 안된다. (즉, CRUD 기능을 나타내는 것은 URL에 사용하지 않는다.)
ex) GET /members/show/1 → GET /members/1
ex) GET /members/insert/2 → POST /members/2
3. 경로 부분 중 변화하는 부분은 유일한 값으로 대체한다. (즉, :id는 하나의 특정 resource를 나타내는 고유값이다.)
ex) student를 생성하는 route : POST /students
ex) id=12인 student를 삭제하는 route : DELETE /students/12
REST API 설계 규칙
1. 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다.
ex) http://restapi.example.com/houses/apertments
2. URL 마지막 문자로 슬래시(/ )를 포함하지 않는다.
- URL에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며,
URL가 다르다는 것은 리소스가 다르다는 것이고,역으로 리소스가 다르면 URL도 달라져야한다. - REST API는 분명한 URL를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URL 경로의 마지막에는 슬래시(/ )를 사용하지 않는다.
3. 하이픈(- )은 URL 가독성을 높이는데 사용한다.
- 불가피하게 긴 URL경로를 사용하게 된다면 하이픈을 사용해 가독성을 높여준다.
4. 밑줄(_)은 URL에 사용하지 않는다.
- 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.
5. URL 경로에는 소문자가 적합하다.
- URL 경로에 대문자 사용은 피하도록 한다.
- PFC 3986(URL 문법 형식)은 URL 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이다.
6. 파일확장자는 URL에 포함하지 않는다.
- REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URL안에 포함시키지 않는다.
- Accep header를 사용한다.
ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)
ex) GET /members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)
7. 리소스 간에는 연관 관계가 있는경우
- /리소스명/리소스 ID/관계가 있는 다른 리소스명
ex) GET : /users/{userid}/devices (일반적으로 소유 'has'의 관계를 표현할 때)
REST API
REST 기반으로 서비스 API를 구현한 것
RESTful
HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스이다. 기본적으로 개발자는 HTTP 메서드와 URI만으로 인터넷에 자료를 CRUD 할 수 있다.
또한 RESTful은 일반적으로 REST 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
REST API를 제공하는 웹서비스를 RESTful하다고 할 수 있다.
RESTful API 개발 원칙
1. 자원을 식별할 수 있어야 한다.
- URL (Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.
- Server가 제공하는 정보는 JSON 이나 XML 형태로 HTTP body에 포함되어 전송 시킨다.
2. 행위는 명시적이어야 한다.
- REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않다. 기존의 웹 서비스 처럼, GET을 이용해서 UPDATE와 DELETE를 해도 된다.
- 다만 REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.
3. 자기 서술적이어야 한다.
- 데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 어플리케이션을 실행 해야 하는지를 알 수 있어야 한다.
- 즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다
4. HATEOS (Hypermedia as the Engine of Application State)
- 클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
- REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.
- 이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼 링크를 제공한다.
- 클라이언트는 이 하이퍼 링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.
RESTful의 목적
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
RESTful한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일괄적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이다. 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.
RESTful API
REST의 특징을 지키는 API를 의미한다.
RESTful API의 장점
확장성
REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다. 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.
유연성
RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 한다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다. 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다.
독립성
REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.
Reference
AWS - RESTful API를 사용하면 어떤 이점이 있나요?
wishket - API란? 비개발자가 알기 쉽게 설명해드립니다!
'🖥CS > 기술면접대비🔎' 카테고리의 다른 글
| http와 https (2) | 2022.12.02 |
|---|---|
| [Java] static, final, staic final 차이 (0) | 2022.11.17 |
| [Java] 접근 제어자(private, default, protected, public) (0) | 2022.11.02 |
| Java Object Class (0) | 2022.10.25 |
| 객체 지향 프로그래밍 (0) | 2022.10.21 |