API 설계

리소스

URI는 Uniform Resource Identifier 입니다.

API의 가장 중요한 것은 리소스의 식별(Resouce identify)하는 것입니다.

따라서 대상과 대상하는 행위를 분리해야 합니다.

이를 테면

알고리즘 조회

알고리즘 코드 구현

알고리즘 문제 제출

...

위의 리소스는 알고리즘입니다.

하지만 리소스로만 API 를 설계하게 된다면 동일한 API가 다른 기능을 해야할 경우가 대부분입니다.

# 예제
- 알고리즘 문제 조회 /algos/{problem_num} -> 아래 URI랑 같은데?
- 알고리즘 문제 제출 /algos/{problem_num} -> 위 URI와 같은데?

그렇다면 이를 어떻게 구분해야 할까요?

행위

위 문제를 해결하기 위해 메서드를 사용합니다.

주요 메서드는 다음과 같습니다.

• GET : 리소스를 조회합니다.
• POST: 요청 데이터를 처리하고, 주로 등록에 사용합니다.
• PUT : 요청이 들어왔을 때 해당 요청이 있다면 덮어쓰고, 없으면 생성합니다.

PUT과 POST

PUT과 POST 메서드의 가장 큰 차이는 리소스를 처리할 때 해당 리소스를 클라이언트가 알고 있느냐 없느냐의 차이입니다.

이를테면 요청을 보낼 때 해당 리소스의 위치를 클라이언트가 알고있는 경우

• /algo/425121235

위와같은 경로로 요청을 보내게 됩니다

하지만 POST의 경우 생성 요청을 보내게 된다면 해당 요청의 시퀀스(새로 채번할 문제 번호)는 서버에서 처리하게됩니다. (클라이언트는 얘가 몇번째 문제인지 알 길이 없음)

• /algo ( )<- ???

• PATCH : 리소스의 일부를 변경할 때 사용합니다.
• DELETE : 리소스를 삭제할 때 사용합니다.

위 주요 메서드들을 가지고 비즈니스 로직상에서의 프로세를 구분할 수 없는 경우

POST 메서드를 사용합니다.

HTTP 메서드의 속성

1. 안전 : 호출해도 리소스를 변경하지 않는다. ( GET )

2. 멱등 : 여러번 호출하더라도 같은 결과를 응답한다. (POST는 멱등이 아니다. ex. 중복결제)

   활용 : 클라이언트와 통신중 서버가 갑자기 장애가 발생할 경우 여러번 요청해도 되나? 의 판단 근거로 작용한다.

3. 캐시 가능 : 주로 GET과 HEAD 정도만 캐시로 사용한다.

출처 :https://javaworld.co.kr/112

데이터 전송 ( 클라이언트 -> 서버)

전달 방식

1. 쿼리 파라미터 ( GET )
2. 메시지 바디 ( POST, PUT, PATCH ) (GET도 가능은 함!)

상황

1. 정적 데이터 조회 : 이미지, 텍스트
   일반적으로 쿼리 파라미터 없이 경로만 사용하는 경우가 많습니
2. 동적 데이터 조회 : 검색, 게시판 목록
3. HTML FORM을 통한 데이터 전송 ( GET과 POST 만 가능)
   Content-Type: application/x-www-form-urlencoded
4. HTTP API를 통한 데이터 전송 : 여러가지 비즈니스 로직 및 데이터 변경 가능, 서버 to 서버, 앱, 웹
   Content-Type: application/json을 주로 사용합니다 (사실상 표준)