Step9. REST API

이신욱·2023년 8월 11일
0

Spring

목록 보기
9/11
post-thumbnail

REST API란 RESTful한 API란 뜻이다. 그럼 API가 무엇인지, REST가 무엇인지 부터 알아보자

1. API


API는 ‘Application Programming Interface’의 약자이다.
뭔가 어려운 용어 같이 보였지만 API도 결국 '인터페이스'이다.

OOP에서 의미하는 인터페이스란 "다른 클래스 사이의 중간 매개 역할을 담당한다."라고 했었는데

API의 Interface는 응용프로그램에 대한 인터페이스로

프로그램과 프로그램 사이를 매게하는 일종의 약속된 매커니즘이다.

이를 통해 다양한 서비스나 프로그램이 서로 통신하고 기능을 제공할 수 있다.

예를 들면, 정보를 검색하거나 어떤 기능을 수행하고 잘 때 API는 클라이언트가 원하는 것을
시스템에 전달할 수 있도록 한다.

(OOP의 인터페이스와 같다는 것이 아니다. 수행하는 역할이 비슷하다는 것)

2. REST


REST(REpresentational State Transfer)는 프로토콜이나 표준이 아닌 하나의 아키텍처 스타일이다.
단어 하나하나를 직역해보면

  • REpresentational : 표현
  • State : 상태
  • Transfer : 전송

즉, 웹 리소스(자원)의 상태를 전송하고 표현하는 방식을 의미한다.

어떻게 상태를 전송하고 표현할까

HTTP라는 프로토콜을 이용해서 웹에서 제공하는 모든 자원들을 하나하나 가리킬 수 있는 고유한 주소(URI)를 이용, HTTP Method를 통해 정보 가공 작업(CRUD)를 처리한다.

REST의 구성요소

1. Resource

웹서버가 관리하는 모든것이다.
Resource는 URI를 통해 고유한 주소로 지정하여 하나하나 식별이 가능하다.

2. Verb

HTTP에 있는 Method를 통해 CRUD를 수행한다.

  • CREATE -> POST
  • READ -> GET
  • UPDATE -> PUT | PATCH
  • DELETE -> DELETE

3. Representation

클라이언트에서 자원의 상태를 가공하라는 요청을 하고, 서버에서 요청 처리를 한 후
응답을 보낸다.

REST의 특징

  1. Uniform Interface
    URI로 지정한 Resource에 대한 조적을 통일되고 제한적인 인터페이스로 수행한다.

  2. Stateless
    무상태성을 갖는다.
    따라서 작업을 위한 상태정보를 따로 저장하고 있지 않다.
    세션이나 쿠키를 따로 저장하지 않기에, 들어오는 요청만 단순히 처리하면 된다.

  3. Caching
    REST는 HTTP의 기능을 그대로 사용하는것을 지향하기에 HTTP의 기존 인프라를 그대로 활용할 수 있다.
    따라서 HTTP의 캐싱 기능을 사용할 수 있다.

  4. Self-descriptiveness
    REST API 메세지만 보고도 쉽게 이해할 수 있는 자체적인 표현 구조를 갖는다.

  5. Client-Server Architecture
    서버와 클라이언트의 역할이 확실히 구분되어 각각이 개발해야할 내용이 명확해지고 서로의 의존성이 줄어든다.

  6. Layered Architecture
    REST는 다중 계층으로 구성될 수 있으며 보안, 암호화 계층 등을 추가해 구조상 유연성을 둘 수 있고, PROXY, 게이트웨이같은 네티워크 기반 중간매체를 활용할 수 있다.

3. REST API


앞서 설명한 내용을 종합해보면, REST API는 클라이언트가 자신의 컴퓨터에서 기능을 실행하는 것이 아니라, HTTP의 URI 주소를 활용하여 서버측에서 기능을 처리하게 된다.

REST API는 HTTP 프로토콜의 다양한 기능을 최대한 활용하는 것을 목표로 하며, 이를 위해 HTTP 메서드를 직접 활용한다.

클라이언트가 원하는 작업을 HTTP 메서드를 통해 서버에 전달하고, 서버는 해당 요청을 수신하여 적절한 응답을 반환한다.
이렇게 함으로써 클라이언트와 서버간의 효율적인 상호작용이 가능해진다.

4. REST API 작성 규칙


  • URI는 행위가 아닌 정보의 자원을 표현할 것(리소스명은 동사보다는 명사를 사용)

    • 잘못된 예 : GET .../users/delete/2
    • 옳은 예 : DELETE .../users/2
    • (예외적으로 컨트롤 자원을 의미하는 경우 동사를 허용)
  • 자원에 대한 행위는 HTTP Method로 표현할 것

  • 소문자를 사용할 것

  • 언더바(_)를 사용하지 않고, 하이픈(-)을 사용할 것

  • 계층 관계를 나타내기 위해 슬래시(/)를 사용할 것

  • URI의 마지막에 슬래시(/)를 포함하지 않을 것

    • 잘못된 예: .../profile/
    • 옿은 예: .../profile
  • 파일의 확장자는 URI에 포함하지 않을 것
    • 잘못된 예: .../images/avatar.jpg
    • 옳은 예 : .../images/avatar

4. 마무리


REST API를 공부하면서 내가 스프링을 배우면서 만들려고 하는것이 정확하게 무엇인지 되짚어볼 수 있었다.
프로젝트의 구조와 데이터의 흐름을 더 자세히 파악하게 개발할 수 있는 계기가 될 것 같다.

profile
1인분 하는 개발자 되기

0개의 댓글