Skip to content

Latest commit

 

History

History
47 lines (38 loc) · 2.58 KB

REST.md

File metadata and controls

47 lines (38 loc) · 2.58 KB

REST

  • HTTP URI를 통해 자원을 명시하고, HTTP 메소드를 통해 CRUD 연산을 적용하는 것이다.
    • 서비스 호출 프로토콜로 HTTP를 사용한다. : 서비스는 HTTP 엔드포인트로 노출되고 HTTP 프로토콜을 사용해 서비스와 데이터를 교환한다.
    • 서비스와 행동 양식을 HTTP 표준 동사에 매핑한다. : POST, GET, PUT, DELETE에 매핑하고 대부분의 서비스에 있는 CRUD 함수에 매핑된다.
  • 서비스끼리 교환하는 모든 데이터는 JSON을 사용한다.
  • HTTP 상태 코드를 사용해 서비스 호출 상태를 전달한다.
  • 서버와 클라이언트의 역할이 명확이 구분된다.
  • 장점 : 메시지를 읽는 것만으로도 의도를 이해할 수 있어 가독성이 좋고, 사용이 쉽다.
  • 단점 : 메소드의 형태가 제한적이다. 메소드를 잘못 사용할 가능성이 있다. (POST로 삭제, 갱신)

구성

  • URI, HTTP METHOD, 표현

클라이언트 - 서버 구조

  • 서버는 API 제공
  • 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조 → 클라이언트와 서버간의 의존성이 줄어든다.

HTTP METHOD

  • POST : 해당 URI를 요청하면 리소스를 생성한다.
  • GET : 해당 리소스를 조회, 리소스를 조회하고 해당 도큐먼트의 자세한 정보를 가져온다.
  • PUT : 해당 리소스를 수정한다.
  • DELETE : 리소스를 삭제한다.
  • HEAD : GET방식과 동일하지만, 응답에 BODY가 없고 응답코드와 HEAD만 응답한다.
    • 웹서버 정보확인, 헬스체크, 버전확인, 최종 수정일자 확인등의 용도로 사용된다.

GET vs POST

  • GET은 동일한 요청을 여러 번 해도 항상 동일한 응답이 오지만, POST는 리소스의 생성이나 변경을 위해 설계된 것이므로 그렇지 않을 수 있다.
  • POST는 body에 데이터를 담아 요청하지만, GET은 body에 데이터를 담을 수 없고 URL에 포함시킨다.
  • GET은캐싱이 가능하지만, POST는 불가능하다.
  • GET은 조회, POST는 데이터를 변경할 때 사용한다.

URI 설계 시 주의할 점

  • '/' 구분자는 계층 관계를 나타내는데 사용한다.
  • URI 마지막 문자로 '/'를 포함하지 않는다.
http://restapi.example.com/houses/apartments/ (X)
http://restapi.example.com/houses/apartments  (0)
  • '-'는 URI 가독성을 높이는데 사용
  • '_'은 URI에 사용하지 않는다.
  • URI 경로에는 소문자가 적합하다.
  • 파일 확장자는 URI에 포함시키지 않는다.