[Backend] RESTful 하다는 것

✨ RESTful하다 : URI를 통해 자원을 명시하고 HTTP METHOD 로 가져오도록 설계된 것

• RESTful한 API를 설계하면 서버의 기술이나 플랫폼이 변경되어도 클라이언트가 수정할 내용은 없다.
  • 서버에서 정보를 저장하지 않는 무상태성과 관련됨

Reference

• gmlwjd9405님 rest and restful
• AWS블로그 what is restful api
• round-round님 REST API의 단점 3가지

01. 서론

RESTful하다의 의미는 항상 헷갈린다. RESTful 하다는게 어떤 의미일까요? 라는 물음에는 어떤 답변을 내는 것이 최선일까 ?

일단, 내가 이해하는 RESTful 은 1 ) URL 잘 정의하고 2 ) URL 로 자원 잘 가져오는 것 이다.
그럼 여기서 '잘' 이라는 게 뭔가요? 라고 물으면 규칙이 정한대로.. 라고 말할 수 있겠다.
GET, POST, PUT, DELETE 중 적절한 METHOD 를 선택해서 구현할 수 있다.
이 때, Login 정보 같은 것은 POST 로 보내야 보안에 조금 더 신경 쓸 수 있다.

하지만 나는 이 지식이 모호하다고 생각한다 !
그럼 이참에 RESTful 하다는 것에 대해 정리해보자.

02. Representational State Transfer

1 ) 정의

• 어떤 자원(Resource)을 이름으로 구분하여 상태를 주고 받는 모든 것
  • 그러니까, REST 라는 건, 내가 요청할 Resource 를 이름으로 구분해서 그 Resource 의 상태에 대해 주고 받는 것이다.
  • Resource 라는 것은 소프트웨어가 관리하는 것들(문서, 이미지, 데이터 등)을 말한다.

2 ) 구체적인 개념

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)를 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation 을 적용하는 것

• a ) Resource 를 명시할 수 있는 URI 를 사용하기
• b ) HTTP Method 를 이용하여 CRUD Operation 적용하기
  • GET, POST, PUT, DELETE

✨Resource Oriented Architecture (ROA) : 설계의 중심에 Resource 가 있고, HTTP Method 를 통해 Resource 를 처리하도록 설계된 아키텍쳐

3 ) 구성 요소

• 자원(Resource): URI
• 행위
• 표현

03. 장단점

1 ) 장점

• 확장성
  • 클라이언트와 서버의 상호 작용을 최적화하고 무상태성을 이용하여 서버와 클라이언트를 분리
• 유연성
  • 클라이언트와 서버가 분리됨으로써 서버의 플랫폼이나 기술의 변경이 클라이언트에 영향을 주지 않음
  • API 가 잘 정의되어 있으면 서버의 플랫폼이 바뀌어도 클라이언트를 변경하지 않아도 됨
• 독립성
  • API 설계와 사용되는 기술이 분리됨

2 ) 단점

• 안티 패턴으로 사용될 가능성이 높음
  • 예를 들어, GET, POST, PUT, DELETE 중 갱신, 삭제임에도 POST 를 사용하는 경우
  • 예를 들어, HTTP Response code 를 2, 3개만 활용하는 경우
• 정해진 표준이 없음
• RDBMS 에 적합하지 않은 JSON 구조
  • 보완 방법 : Google : API links vs keys: Why you should use links, not keys, to represent relationships in APIs

04. 기타

1 ) URI VS. URL

URI 는 URL 을 포함한다. velog.io/write ,velog.io/edit 같은 것들을 URI 라고 하고 각각을 URL 이라고 한다.

• URI (Uniform Source Identifier)
  • 자원을 식별하기 위한 식별자
• URL (Uniform Resource Locator)
  • 특정 자원의 위치를 가리키는 것