REST API

조예슬·2022년 10월 12일
0

Server

목록 보기
2/6
post-thumbnail

REST 는 Representational State Transfer 의 줄임말이다.
즉, 서버의 리소스(자원)을 정의하고 리소스에 대해 주소를 지정하는 방법을 말한다.
이러한 리소스 지향 아키텍쳐를 모든 것을 가급적이면 리소스를 중심으로, 명사로 표현하는 것으로 이야기 할 수 있.

말이 어렵다.. 조금 더 쉬운 설명을 가져와봤다 !....

서버에 요청을 보낼 때는 주소를 통해 요청의 내용을 표현한다. 주소가 /index.html이면 서버의 index.html을 보내달라는 뜻이고, /about.html이면 about.html을 보내달라는 뜻이다.

항상 html을 요청할 필요는 없다. css나 js 또는 이미지 같은 파일을 요청할 수도 있고 특정 동작을 요청할 수도 있다. 요청의 내용이 주소를 통해 표현되므로 서버가 이해하기 쉬운 주소를 사용하는 것이 좋은데, 이때 등장하는 개념이 바로 REST 이다!

이런 REST 아키텍쳐를 준수하는 API가 바로 REST API 이다 !
(그리고 이런 REST를 따르는 서버를 RESTful하다 라고 표현한다. 우리는 최대한 RESTful한 API를 만드는 것에 집중하는 것이 중요하다.)

아니 그럼 API는 또 뭔데?
Application Programming Interface 의 줄임말이다.
API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

본격적으로 REST API에 대해서 알아보자 !


1. REST API 의 핵심

REST API 설계 시 가장 핵심은 다음 두 가지이다.

💡 자원 (resource) - URI는 정보의 자원을 표현해야 한다.
💡 행위 (verb) - 자원에 대한 행위를 HTTP Methods(GET, POST, PUT, DELETE)로 표현한다.

2. REST API 핵심 규칙

1) URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용한다.)

DELETE /members/update/1

위와 같은 방식은 REST를 제대로 적용하지 않은 URI이다. URI는 자원을 표현하는데 중점을 두어야 한다. update와 같은 행위에 대한 표현이 들어가서는 안된다.

2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현해야 한다.

위의 잘못 된 URI를 HTTP Method를 통해 수정해 보면 아래와 같다.

DELETE /members/1

회원정보를 가져올 때는 GET, 회원 추가 시의 행위를 표현하고자 할 때는 POST METHOD를 사용하여 표현한다.

- 회원정보를 가져오는 URI

GET /members/show/1     (x)
GET /members/1          (o)

- 회원을 추가할 때

GET /members/insert/2 (x)  - GET 메서드는 리소스 생성에 맞지 않습니다.
POST /members/2       (o)

[참고]HTTP METHOD의 알맞은 역할
POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있다.

  • POST : POST를 통해 해당 URI를 요청하면 리소스를 생성합니다.
  • GET : GET를 통해 해당 리소스를 조회합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.
  • PUT : PUT를 통해 해당 리소스를 수정합니다.
  • DELETE : DELETE를 통해 리소스를 삭제합니다.

✔️ 이처럼 URI는 자원을 표현하는 데에 중점을 두고, 행위에 대한 정의는 HTTP METHOD를 통해 하는 것이 REST한 API를 설계하는 핵심 규칙이다

3. URI와 URL의 차이 ?

- URI

Uniform Resource Identifier
통합 자원 식별자 (자원을 나타내는 주소)
자원을 나타내는 유일한 주소

- URL

Uniform Resource Locator
통합 자원 지시자
특정 서버의 한 리소스에 대한 구체적인 위치 서술

즉, URL ⊂ URI 라고 생각하면 된다 !

자 그렇다면 여기서 Quiz !!
다음 세 가지는 URI 일까? URL 일까?
https://sopt.org/
https://github.com/IN-SOPT-SERVER
https://www.youtube.com/results?search_query=sopt

아놔 당근 URI가 범위가 더 크니까 셋 다 URI 겠지요 !!
그렇다면 이들 중 URL은 ??

정답은, 제일 하단에 있는 유튜브 링크를 제외하고 모두이다 !
제일 하단의 유튜브 예시는 리소스의 위치와는 상관이 없기 때문이다.

URI는 식별, URL은 위치를 가르킨다 는 점만 잘 기억하면 된다.

4. REST API의 기준

4-1) 기준

  1. 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
  2. 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션
    • 요청 간에 클라이언트에 대한 데이터가 저장되지 않음
    • 각 요청이 분리되어 있고 서로 연결되어 있지 않음
  3. 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터
  4. 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템
  5. 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스

4-2) 규칙

API의 라우팅을 직접해야하기 때문에 아래의 규칙을 꼭 기억해서 올바른 엔드포인트를 정의해야한다.

  1. / 는 계층 관계를 표현합니다.
  2. / 는 URI 마지막에 포함하지 않습니다.
  3. 가독성을 높이기 위해 불가피한 경우에는 - 를 사용합니다.
  4. 언더바(_)는 사용하지 않습니다.
  5. 소문자를 사용하는 것이 적합합니다.
  6. 파일 확장자를 포함시키지 않습니다.
  7. 리소스 간의 연간 관계를 표현합니다.
profile
코딩 해라 스리스리 예스리 얍!

0개의 댓글