반응형
REST API 란?
(REpresentational State Transfer)
● RESTful : REST의 기본원칙을 성실히 지킨 서비스 디자인
● REST : HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한 아키텍처
● REST API : REST를 기반으로 서비스 API를 구현한 것 (= 도메인 주소 작성 규칙(규약?))
REST API의 구성
// 구성요소 | 내용 | 표현방법
자원 | 자원 | URI(EndPoint)
행위 | 자원에 대한 행위 | HTTP 요청 메서드
표현 | 자원에 대한 행위의 구체적 내용 | 페이로드(payload)
반응형
REST API 설계 원칙
1. URI는 리소스를 표현해야 한다.
- 리소스를 식별할 수 있는 이름은 동사보다는 명사를 사용한다.
2. 리소스에 대한 행위는 HTTP 요청 메서드로 표현한다.
- HTTP 요청 메서드 : 클라이언트가 서버에게 요청의 종류와 목적을 알리는 방법이다.
// HTTP 요청 메서드 | 종류 | 목적 | 페이로드
GET | index/retrieve | 모든 / 특정 리소스 취득(가져오기) | X
POST | create | 리소스 생성(게시하기, 만들기) | O
PUT | replace | 리소스의 전체 교체(대체하기, 덮어쓰기) | O
PATCH | modify | 리소스의 일부 수정 | O
DELETE | delete | 모든 / 특정 리소스 삭제 | X
# example
# BAD -> GOOD
# Todos 가져오기
GET /getTodos/1 -> GET /todos/1
GET /todos/show/1 -> GET /todos/1
# Todos 삭제하기
GET /todos/delete/1 -> DELETE /todos/1
# 전체 유저 데이터 조회
GET /getUsers -> GET /users
# 특정 유저 데이터 조회
GET /getUser -> GET /users/{user_id}
# 유저 이름순으로 정렬
POST /users?sortBy=name -> GET /users?sortBy=name
# 특정 유저 정보
GET /get_user_info -> GET /users/{user_id}/info
# 유저 생성
POST /createUsers -> POST /users
# 특정 지역에 있는 유저 목록 조회
GET /getUsersByLocation -> GET /location/{location_id}/users
-> 또는 users/locations{locaton_id}
# 특정 유저의 전체 포스팅 목록 가져오기
GET /users/{user_id}/posts
# 특정 유저의 새 글 쓰기
POST /users/{user_id}/post
# 특정 유저의 특정 포스트 삭제
DELETE /users/{user_id}/posts/{post_id}
# 특정 포스트에 댓글 달기
POST /posts/{post_id}/comments
# 특정 포스트에 댓글 가져오기
GET /posts/{post_id}/comments
# 파일명 명시 X, 데이터 타입은 헤더에 명시되어 있음!
GET /users.json
REST API를 알아보는 시간이었습니다.
틀린 내용은 댓글로 알려주시면 감사하겠습니다.
반응형