[웹개발] REST API(3)

REST의 안티 패턴

GET / POST를 이용한 터널링

• 메서드의 실제 동작은 리소스를 업데이트하는 내용인데, HTTP PUT을 사용하지 않고 GET에 쿼리 파라미터로 method=update와 같이 넘겨서 이 메서드가 수정 메서드임을 명시하는 경우
• 또는 Create가 아닌데도 JSON body에 오퍼레이션을 넘기는 형태
• HTTP 메서드 사상을 따르지 않았기 때문에 REST라고 부를 수도 없고, 웹 캐시 인프라 등도 사용이 불가능하다.

 

자기 서술성(Self-descriptiveness) 속성을 사용하지 않는 경우

• REST는 쉽게 정의된 메시지 포맷에 의해서 API를 쉽게 이해할 수 있어야 한다.
• 위에서 언급한 GET이나 POST를 이용한 터널링은 대표적으로 자기 서술성을 사용하지 않는 경우이다.

 

HTTP Response Code를 사용하지 않는 경우

• 성공은 200, 실패는 500과 같이 1~2개의 Code만 사용하는 경우
• 에러도 200으로 정의한 후 별도의 에러 메시지를 Code와 함께 보내는 경우
• REST 디자인 사상에도 어긋나고, 자기 서술성에도 어긋난다.

 

 

REST의 단점들

REST는 분명히 좋은 아키텍처이지만 좋은 점만 있는 것은 아니다. REST의 단점들을 살펴보자.

• REST는 점대점 통신 모델을 기본으로 하기 때문에 서버와 클라이언트가 연결을 맺고 상호 작용해야 하는 어플리케이션 개발에는 적당하지 않다.
• REST는 보안과 통신 규약 정책 같은 것은 전혀 다루지 않기 때문에 개발자는 이에 대한 설계와 구현을 도맡아서 해야 한다.
• REST는 HTTP에 상당히 의존적이다.
• CRUD 4가지 메서드만 제공한다. 대부분의 일들을 처리할 수 있지만, 4가지 메서드만으로 처리하기에 모호한 표현이 있다.
• REST는 표준 규약이 없기 없기 때문에 자체 표준을 정해야 하는데, 개발에 있어 이를 관리하기가 어렵다.
• 기존의 전통적인 RDBMS에 적용시키기 어렵다.

 

 

 

 

REST API의 보안

근래에 대부분의 서비스 시스템들은 API를 기반으로 통신을 한다. 그렇기 때문에 API 보안은 매우 중요하다. REST API의 보안에 대해서 살펴보자.

• 인증 : 누가 API를 호출하는지 확인하는 절차
• 인가 : 사용자가 해당 리소스를 사용할 권한이 있는지 확인하는 절차
• 네트워크 레벨 암호화 : 해커 등이 중간에 데이터를 낚아채서 볼 수 없게 네트워크 프로토콜 레벨에서 처리하는 것
• 메시지 무결성 보장 : 외부 요인에 의해서 변조가 되지 않게 방지하는 것
• 메시지 본문 암호화 : 전체 메시지를 암호화하거나 특정 필드만 암호화하는 방법

---

Reference

• RESTful API 이란
• REST API