티스토리 뷰

반응형

Rest API 개발 순서

 

RestFull API를 개발함에 있어서 다음과 같은 절차를 통해 설계 및 개발을 진행하는 것이
가장 합리적이지 않을까 해서 제안 해 봅니다.

RestFull API를 사용하는 시스템은 주로 개방형 시스템을 지향 하기 마련인데,
개방형 시스템의 가장 반대적 요소로 취약점이 많이 노출 된다는 점 입니다.

따라서 RestFull API를 서비스 하고자 할 시에는 다음과 같은 절차에 따라 진행 하는 것이
가장 합리적이라 할 수 있습니다.

1. 서비스 하고자 하는 기능 분류
   가. 조회성 기능 ( 특정정보의 요청 등 )
     1) 단건 응답 형
     2) 리스트 형태의 응답 형

   나. 기능(동작) 관련
     1) 제공하고자 하는 기능에 대한 데이타 특성 분류
     2) 제공하고자 하는 기능의 동작 특성 분류 ( INSERT , UPDATE, DELETE 등 )
    
2. 데이타의 유형 분류
   가. 제공되는 데이타의 중요도에 따른 분류
   나. 리스트 형태의 데이타 조회에 따른 성능(부하) 관련 분류
   라. 제공되는 데이타의 보안적 측면에 따른 분류
     1) 사용자의 개인정보를 포함 하는지 여부
     2) 기업의 중요정보를 포함 하는지 여부

3. 네트워크 보안 관련
  가. 중요데이타의 네트워크 구간 보호를 위한 SSL 통신 (HTTS)
  나. 외부로 부터 데이타 노출 차단을 위한 데이타 암호화 처리

4. 정보보안을 위한 취약점 점검

5. Rest API의 호출자 인증 방법

 

Rest API는 Http의 Method 별로 기능이 분류 됩니다.

1. GET      조회
2. POST      등록 또는 요청
3. PUT      수정 또는 변경
4. DELETE    삭제


이는 W3C 규격의 Method 입니디만, 이는 개방형을 추구 함에 있어서는
문제가 없습니다.

다만, 정보보안을 위한 취약점 점검을 수행 할 경우에는 문제점이 발생 하게 됩니다.
이는 정보보안의 취약점 점검 시 GET을 사용하지 말도록 권고 하고 있기 때문입니다.

따라서, 정보보안의 취약점 점검을 수행하는 시스템의 경우에는 사전에 GET사용 가능여부에
대하여 협의가 진행되는 것이 가장 합리적 입니다.

협의 진행에 따라 GET 사용가능 여부가 결정되고, 상황에 따라 GET의 사용을 배제 할 필요가 있기 때문입니다.

반응형
250x250
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/01   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함