[면접대비] RESTful API

REST(Representational State Transfer)ful API: REST 의 기본 원칙을 성실히 지킨 서비스 디자인이다. Resource Oriented Architecture으로, API 설계의 중심에 자원(Resource)이 있고 HTTP Method 를 통해 자원을 처리하도록 설계하는 것이다.

REST 6 가지 원칙

• Uniform Interface
• Stateless: 상태저장 없이 요청만을 단순 처리 할 수 있음.
• Caching: HTTP의 캐싱 기능 활용 가능.
• Client-Server
• Hierarchical system
• Code on demand

REST API 제대로 알고 사용하기 : NHN Cloud Meetup

 

RESTful한 API 를 디자인

1. 리소스 와 행위 를 명시적이고 직관적으로 분리한다.

• 리소스: URI(Uniform Resource Identifier)으로 자원 자체를 식별하는 문자열 시퀀스. 명사로 표현되어야 한다.
• 행위: HTTP Method로 표현한다.
  •  GET(조회), POST(생성), PUT(기존 entity 전체 수정), PATCH(기존 entity 일부 수정), DELETE(삭제)로 명시한다.

2. Message 는 Header 와 Body 를 명확하게 분리해서 사용한다.

• 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등은 header 에 담는다.
• 데이터 모델링을 위한 객체(Entity)는 body 에 담는다.
• header 와 body 는 http header 와 http body 로 나눌 수 있다.

MIME type은 뭐고, Content-type은 뭔데?

MIME 타입에 대한 내용. application/json의 의미에 대해 설명한다.

텍스트만 보낼 수 있던 SMTP의 단점을 보완하기 위해 다른 파일을 전송할 수 있도록 MIME로 인코딩하였다. 
MIME로 인코딩한 파일을 Content-Type 필드를 헤더에 담으며, 전송된 자원의 형식을 명시한다. 
바이너리는 프로그램을 말한다. 이진법을 사용하므로 binary로 명시한다.

 

 

3. API 버전을 관리한다.

• 환경은 항상 변하기 때문에 API 의 signature 가 변경될 수도 있음에 유의한다.
• 특정 API 를 변경할 때는 반드시 하위호환성을 보장해야 한다. 이전 버전의 사이트도 잘 돌아갈 수 있도록 한다.

4. 서버와 클라이언트가 같은 방식으로 요청하도록 한다.

• 브라우저는 form-data 형식의 submit 으로 보내고 서버에서는 json 형태로 보내는 식의 분리보다는 json 으로 보내든, 둘 다 form-data 형식으로 보내든 하나로 통일한다.
• 다른 말로 표현하자면 URI 가 플랫폼 중립적이어야 한다. 하나의 서비스를 제공하면 다양한 플랫폼의 클라이언트가 서비스를 받아서 사용할 수 있도록 해야 한다.

RESTful API 장점

1. Open API 를 제공하기 쉽다
2. 멀티플랫폼 지원 및 연동이 용이하다.
3. 원하는 타입으로 데이터를 주고 받을 수 있다.
4. 기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.

RESTful API 단점

1. 사용할 수 있는 메소드가 한정적이다.
2. 분산환경에는 부적합하다.
3. HTTP 통신 모델에 대해서만 지원한다.