[REST API] REST API란?

1. REST API

- Representational State Transfer

- 웹의 장점을 최대한 활용할 수 있는 아키텍쳐

- HTTP 요청을 통해 통신함으로써 리소스 내에서 레코드(CRUD)의 작성, 읽기, 업데이트 및 삭제 등의 표준 데이터베이스 기능을 수행함

- 모든 HTTP 메소드는 API 호출에서 사용될 수 있음

 

RESTful API

- REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어

-> 'REST API'를 제공하는 웹 서비스를 'RESTful'하다고 할 수 있음

 

RESTful의 목적

- 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것

- 근본적인 목적 : 성능 향상 X -> 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것

 

 

2. REST 구성

• 자원(RESOURCE) : URI
• 행위(Verb) : HTTP METHOD
• 표현(Representations)

 

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

GET /members/delete/1

-> REST를 제대로 적용하지 않은 URI

-> URI는 자원을 표현하는데 중점을 두어야 함(delete와 같은 행위에 대한 표현이 들어가서는 안됨)

 

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

DELETE /members/1

-> 잘못 된 URI를 HTTP Method를 통해 수정한 것

 

GET /members/insert/2 (X) -> GET 메서드는 리소스 생성에 맞지 않음
POST /members/2       (O)

-> 회원 정보를 등록하는 URI

 

HTTP METHOD

METHOD	역할
POST	리소스 생성, 일부 수정
GET	리소스 조회
PUT	리소스 전체 수정
DELETE	리소스 삭제

 

URI 설계 시 주의할 점

• 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용

http://restapi.example.com/houses/apartments
http://restapi.example.com/animals/mammals/whales

• URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
  • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 함
  • URI가 다르다는 것 -> 리소스가 다르다는 것
  • 리소스가 다르다 -> URI도 달라져야 함
  • 혼동을 주지 않기 위해 URI 경로의 마지막에는 슬래시(/)를 사용하지 않기

  http://restapi.example.com/houses/apartments/ (X)
  http://restapi.example.com/houses/apartments  (0)

 

3) 하이픈(-)은 URI 가독성을 높이는데 사용

• URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI 경로를 사용하게 된다면 하이픈을 사용해 가독성을 높이기

 

4) 밑줄(_)은 URI에 사용하지 않음

• 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 함
• 이런 문제를 피하기 위해 밑줄 대신 하이픈(-)을 사용하는 것이 좋음(가독성)

 

5) URI 경로에는 소문자가 적합함

• URI 경로에 대문자 사용은 피하도록 해야 함
• 대소문자에 따라 다른 리소스로 인식되기 때문
• RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문

 

참고

https://www.ibm.com/kr-ko/topics/rest-apis

https://hahahoho5915.tistory.com/54