본문 바로가기

Network

[HTTP] RESTful API

1. RESTful(Representational State Transfer) API 란?

▶ REST 방식 : API 시스템을 구현하기 위한 아키텍처(=엔드포인트 구조를 구현하는 방식)이고, 이외에도 GraphQL 등이 있다

 

▶  정의

API(Application Programming Interface)에서 전송하는 리소스URI로 표현하고 해당 리소스에 행하고자 하는 의도를 http 메소드로 정의하는 방식 

→ 리소스(URI)를 어떻게 한다(Method+Payload서버로 보내는 데이터(body))

· post : 생성

· get : 조회

· put : 전체수정 / id를 제외한 전부를 우리가 전송한 데이터로 변경, 교체라고 생각하면 됨

· patch : 부분수정 / title을 언급하면 title 만 교체되고 나머지 그대로 

· delete : 삭제 

 

▶ 특징

규정하고 있는 것 : 리소스를 식별할 때는 uri를 통해 식별하고 행위를 할 때는 method를 이용, 결과를 알려줄 때는 응답코드를 통해 알려줌

규정하고 있지 않은 것 : 클라이언트와 서버가 어떤 데이터 타입으로 통신할 것인가 ex) json / xml

 

▶ 장점

 구조만 보더라도 해당 엔드포인트가 제공하는 리소스와 기능을 파악할 수 있기 때문에 직관적이고 간단하다.

▶  URL & URI

URI : 특정 리소스를 식별하는 통합 자원 식별자를 의미, 해당 사이트의 특정 자원의 위치를 나타내는 유일한 주소 

 

URL : 흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약

ex) https://finance.naver.com/login 

 

*주의할 점

url 은 사이트 주소창이 아니다!

url은 프론트엔드가 백엔드 개발자에게 기능을 요청할 때 보내는 주소!

2. RESTful API 설계규칙

▶ 정보를 명확하게 표현해야 함

ex)"유저들 중 1번 유저를 표시" → GET/user/1 → GET/users/1

 

▶ 동사를 포함하지 않음. / resource에 대한 행위를 HTTP Method(get, post, update, delete)로 표현

ex) GET delete/user/1  → DELETE /user/1

 

▶ 리소스 사이에 연관 관계가 있는 경우(리소스 / 고유 ID / 관계있는 리소스)

ex) GET/users/{user_id}/profile

▶ 파일의 경우 확장자를 URI를 포함시키지 않음.

ex) GET users/{user_id}/profile.jpg(x) / payload의 포맷은 headers에 accept를 사용

 

▶ 마지막문자로 / 를 포함하지 않음

 

▶ URI가 길어지는 경우 - 를 사용하여 가독성을 높임

 

▶ _를 사용하지 않음

 

▶ URI 경로에는 대문자를 사용하지 않음

 

3. RESTful API 못한 설계 예시

4. Path parameter 와 Query parameter

▶ Path parameter : 각자의 url을 만드는 것이 아니라 특정 상품을 가져올 수 있음

 

put : 전부 고친다.

patch : 조금만 고친다. / path parameter로 타켓팅 해서 원하는 부분만 수정 가능

delete : 바디에 내용을 담을 수 없다. 그렇기 때문에 패스 파라미터에 내용을 담아서 전달

 

▶ Query parameter : Filtering / Ordering / Pagination / Searching

 

▶ Path parameter vs  Query parameter

 

만약, 패스 파라미터로 3번 상품 불렀는데 없다? 그러면 404 에러 뜬다

그러나, 쿼리 파라미터로 3번 상품 불렀는데 없다? 그러면 빈 리스트 반환

 

 

▣ 출처

생활코딩

위코드 "RESTful AP" 세션

블로그 "https://www.charlezz.com/?p=44767"