[Network] [network] REST API + RESTful

REST

REST(Representational State Transfer)란 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미합니다.

즉, HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)를 명시하고, HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해 해당 자원 (URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

CRUD Operation이란

• Create, Read, Update, Delete를 묶어서 일컫는 말
• REST에서의 CRUD Operation 동작 예시는 다음과 같습니다.
• Create: 데이터 생성(POST)
• Read: 데이터 조회(GET)
• Update: 데이터 수정(PUT, PATCH)
• Delete: 데이터 삭제(DELETE)

REST 구성 요소

• 자원(Resouce) : HTTP URI
• 자원에 대한 행위(Verb) : HTTP Method
• 자원에 대한 행위의 내용(Representations) : HTTP Message Pay Load

REST의 장단점

장점

1. HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
2. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
3. REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
4. 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
5. 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

1. HTTP Method 형태가 제한적이다.
2. 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
3. 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

REST의 특징

1. Server-Client(서버-클라이언트 구조)
2. Stateless(무상태)
3. Cacheable(캐시 처리 가능)
4. Layered System(계층화)
5. Uniform Interface(인터페이스 일관성)

API

API(Application Programming Interface)는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 의미합니다.

REST API

REST API(Representational State Transfer API)란 REST의 아키텍처 스타일을 따르는 API를 의미합니다.

REST API 설계 예시

1. URI는 명사, 소문자를 사용해야한다.

Bad Example <http://soomi.com/Studying>
Good Example <http://soomi.com/study>

1. 마지막에 슬래시(/) 포함하지 않는다.

Bad Example <http://soomi.com/study/>
Good Example <http://soomi.com/study>

1. 언더바 대신 하이폰을 사용한다. 

Bad Example <http://soomi.com/holy_study>
Good Example <http://soomi.com/holy-study>

1. 파일 확장자는 URI에 포함하지 않는다.

Bad Example <http://soomi.com/note.jpg>
Good Example <http://soomi.com/note>

1. 행위를 포함하지 않는다.

Bad Example <http://soomi.com/get-idea/1>
Good Example <http://soomi.com/idea/1>

RESTful

REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 합니다. RESTful API라는 용어는 일반적으로 RESTful 웹 API를 의미하지만, REST API와 RESTful API라는 용어는 같은 의미로 사용 가능합니다. 하지만 REST를 사용했다 하여 모두가 RESTful한 것은 아닙니다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다 말할 수 있으며, 모든 CRUD 기능을 POST로 처리하는 API혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API를 사용하였지만 RESTful 하지 못한 시스템이라 말할 수 있습니다.

RESTful API 작동원리

1. 클라이언트가 서버에 요청 전송한다.
2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인한다.
3. 서버가 요청을 수신하고 내부적으로 처리한다.
4. 서버가 클라이언트에 응답을 반환한다. 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함된다. 또한 클라이언트가 요청한 모든 정보도 포함된다.

RESTful API 클라이언트 요청 구성 요소

• 고유 리소스 식별자
• 서버는 고유한 리소스 식별자로 각 리소스를 식별합니다. REST 서비스의 경우 서버는 일반적으로 URL을 사용하여 리소스 식별을 수행합니다. URL은 리소스에 대한 경로를 지정합니다. URL은 요청 엔드포인트 라고도 하며 클라이언트가 요구하는 사항을 서버에 명확하게 지정합니다.
• 메서드
• 개발자는 종종 HTTP(Hypertest Transfer Protocol)을 사용하여 RESTful API를 구현합니다. HTTP Method는 리소스에 수행해야 하는 작업을 서버에 알려줍니다.

1. GET
2. 클라이언트는 GET을 사용하여 URL의 리소스에 접근합니다. GET 요청을 캐싱하고 RESTful API 요청에 파라미터를 넣어 전송하여 전송 전에 데이터를 필터링 하도록 서버에 지시 가능합니다.
3. POST
4. 클라이언트는 POST를 사용하여 서버에 데이터를 전송합니다. 여기에는 요청과 데이터 표현이 포함됩니다. 동일한 POST를 여러 번 전송 할 경우 동일 리소스를 여러번 생성하는 부작용이 있습니다.
5. PUT
6. 클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트합니다. POST와 달리, RESTful 웹 서비스에서 동일한 PUT 요청을 여러 번 전송해도 결과는 동일합니다.
7. DELETE
8. 클라이언트는 DELETE 요청을 사용하여 리소스를 제거합니다. DELETE 요청은 서버 상태를 변경할 수 있습니다. 하지만 사용자에게 적절한 인증 없으면 요청은 실패합니다.

• HTTP header
• header는 클라이언트와 서버 간 교환되는 메타데이터입니다. 예를 들어, 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공합니다.

1. Data
2. REST API 요청에는 POST, PUT 등 기타 HTTP method가 성공적으로 작동하기 위한 데이터가 포함될 수 있습니다.
3. Parameter
4. RESTful API 요청에는 수행햐아 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있습니다.

멱등성(Idempotence) 메소드란?

몇 번의 동일한 요청을 해도 언제나 동일한 resource의 상태를 보장하는 메소드를 말합니다.

네트워크 상의 문제로 혹은 클라이언트의 실수로 중복 요청해도 문제가 되지 않는 메소드를 뜻합니다.

간혹 idempotent한 메소드를 동일한 response를 반환하는 메소드라고 잘못 알고 있는 경우가 있습니다.

하지만 서버 resource의 상태가 동일하다면 response가 달라도 idempotent한 메소드입니다.

• GET,PUT,DELETE 요청은 idempotent 하다.
• POST 요청은 idempotent 하지 않다.
• PATCH 요청 또한 멱등성을 보장하진 않는다.

파라미터 유형

1. URL 세부정보를 지정하는 경로 파라미터
2. 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터
3. 클라이언트를 빠르게 인증하는 쿠키 파라미터

RESTful API 인증 방법이란

RESTful 웹 서비스는 응답 전 요청을 인증해야합니다. 클라이언트는 신분증이나 운전 면허증을 제시하여 자신의 신원을 증명하듯 신뢰를 구축하기 위해 서버에 자신의 신원을 먼저 증명해야합니다.

• HTTP 인증

HTTP는 REST API를 구현할 때 직접 사용가능한 일부 인증 체계를 의미합니다. 다음은 이러한 체계 중 두 가지입니다.

1. 기본 인증
2. 기본 인증에서 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송합니다. 안전한 전송을 위하여 이 페어를 64자의 세트로 변환하는 인코딩 기술인 base64로 인코딩합니다.
3. 전달자 인증
4. 전달자(bearer)인증은 토큰 전달자에 대한 엑세스 제어를 제공하는 프로세스를 의미합니다. 일반적으로 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화된 문자열입니다. 클라이언트는 리소스에 엑세스 하기 위해 요청 헤더에 토큰을 넣어 전송합니다.

• API Key
• 이 접근 방식에서 서버는 고유하게 생성된 값을 최초 클라이언트에 할당합니다. 클라이언트는 리소스에 접근하려고 할 때마다 고유 API키를 사용하여 본인을 검증합니다. API 키 경우 클라이언트가 이 키를 전송해야되게이 네트워크 도난에 취약하다는 단점이 있습니다.
• OAuth
• OAuth는 모든 시스템에 대해 매우 안전한 로그인 접근을 보장하기 위해 암호와 토큰을 결합합니다. 서버는 먼저 암호를 요청한 다음 권한 부여 프로세스를 완료하기 위해 추가 토큰을 요청합니다. 특정 범위와 수명으로 언제든지 토큰을 확인 가능합니다.

RESTful API 서버 응답 구성 요소

상태 표시줄

상태 표시줄에는 요청 성공 또는 실패를 알리는 3자리 상태 코드가 존재합니다. 예를 들어, 2XX 코드는 성공을 의미하며, 4XX 및 5XX 코드는 오류를 나타냅니다. 3XX 코드는 URI 리디렉션을 나타냅니다.

다음은 일반적인 상태 코드 예시입니다.

• 200 : 일반 성공 응답
• 201 : POST 메서드 성공 응답
• 400 : 서버가 처리할 수 없는 잘못된 요청
• 404 : 리소스를 찾을 수 없음

메시지 본문

응답 본문에는 리소스 표현이 포함됩니다. 클라이언트는 데이터 작성 방식을 XML 또는 JSON 방식으로 정보를 요청할 수 있습니다. 예를 들어, 클라이언트가 Sanghyuk이라는 사람의 이름과 나이를 요청하면 서버는 다음과 같이 JSON 방식으로 표현을 반환합니다.

'{"name":"soomi","age":24}'

헤더

이는 응답에 대한 추가 컨텍스트를 제공하고 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보를 포함합니다.

 

해당 글은 aws 문서와 cs 깃허브를 토대로 작성하였습니다.