REST ?
- Representational State Transfer 의 약어
- 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를
주고 받는 모든 것을 의미- 웹에서 통신을 위해 사용되는 아키텍처
- 전송 관련 상태를 표현하는 구조
- [ 구성 ]
1) 자원(Resource) - URI
2) 행위(Verb) - HTTP METHOD
3) 표현(Representations)
API ?
- Application Programming Interface의 약어
- 정보 사용자가 원하는 것에 도달할 수 있도록 한 인터페이스
- 애플리케이션 소프트웨어의 구현 방식을 몰라도 사용자는 API를 통해 사용 가능
- 정보 제공자와 정보 사용자 간 소통하기 위한 하나의 인터페이스 장치
REST API ?
- REST를 기반으로 서비스 API를 구현한 것
- RESTful하다 --> REST 구조 스타일로 API가 이루어진 서비스!
- CRUD 모두 POST로 처리 --> RESTful 하지 못하다!
[ URI 기본 설계 규칙 ]
1) 슬래시 구분자(/)는 계층 관계를 나타낼 때 사용
http://jungwook.com/houses/apartments2) URI 마지막 문자로 슬래시(/)를 포함하지 않는다
http://jungwook.com/houses/apartments/ (X)3) 밑줄( _ ) 대신 하이폰( - )을 사용한다
http://jungwook.com/users/post-comments4) URI경로는 소문자로 작성한다.
http://jungwook.com/USERS (X)5) 파일 확장자는 URI에 포함하지 않는다
http://jungwook.com/members/soccer/345/photo.jpg (X)6) CRUD 행위는 포함하지 않는다
http://jungwook.com/posts/delete/3 (X)
[ 리소스 원형 종류 ]
: REST API에 URI를 디자인할 때 쓰는 모든 Resource들을 지칭한 말
도큐먼트 / 컬렉션 / 스토어 / 컨트롤러 로 구성
(각 각 완벽한 이해는 힘들다고 생각, 대략적인 느낌을 가져가면 될 듯!)
1) 도큐먼트 ( 단수 )
- DB의 row단위 컬렉션에서 하나의 객체단위로 하는 단일 정보
ex) 1, 2, 3, team1, team2, kim-jungwook 등
2) 컬렉션 ( 복수 )
- 도큐먼트들의 집합 / 관리 주체는 서버
- 어떤 리소스가 도큐먼트의 집합이며, 관리 주체가 서버인 것
ex) projects --> 프로젝트들의 관리 주체는 서버
3) 스토어 ( 복수 )
- 도큐먼트들의 집합 / 관리 주체는 클라이언트
ex) favorites --> 좋아하는 것들의 관리 주체는 클라이언트
장바구니 --> 장바구니는 클라이언트가 관리 주체
4) 컨트롤러 ( 복수 )
- 컬렉션, 스토어의 메서드 기능
- CRUD라는 표준적인 메서드와 논리적으로 매핑되지 않는
애플리케이션의 고유한 행동을 의미- 보통 URI 경로의 마지막에 표시
ex) isExist / register 등등
[ 리소스 원형 예시 ]
1) GET
http://jungwook.com/grades/1/classes/3
: 1학년 3반의 학생 목록을 조회 (URI로 의미파악이 가능한게 REST의 장점)
grades : 콜렉션
1 : 도큐먼트
classes : 콜렉션
3 : 도큐먼트
( 콜렉션과 스토어는 모두 복수로 사용 )
2) GET
http://api.test.com/categories/blouses/shirts/319
: 블라우스 중 셔츠 319번 목록을 조회
categories : 콜렉션
blouses : 콜렉션
shirts : 콜렉션
319 : 도큐먼트
3) PUT
http://api.test.com/members/456/follow
: 현재 회원 idx가 456 에 해당하는 멤버를 follow (친구추가)
members : 콜렉션
456 : 도큐먼트
follow : 컨트롤러
4) POST
http://api.com/items/1/favorites/register
: item idx가 1인 것을 좋아요 목록에 register
items : 콜렉션
1 : 도큐먼트
favorites : 스토어
register : 컨트롤러
[ HTTP METHOD ]
사용자의 Request 요청의 목적 / 종류를 알리는 방법
(GET / POST / PUT / DELETE 그 외에도 HEAD / PATCH 등 존재!)
1) GET : 클라이언트가 일반적으로 정보를 얻을 때 사용 (READ)
Request Body를 사용하지 X
-> url에 params나 querystring 으로 표시2) POST : 클라이언트가 새로운 리소스를 생성할 때 사용 (CREATE)
Request Body를 사용 O
-> Create하고자 하는 data를 담아서 전송3) PUT : 클라이언트가 기존 리소스를 수정할 때 사용 (UPDATE)
Request Body가 존재 O
-> Update하고자 하는 data를 담아서 전송4) DELETE : 클라이언트가 기존 리소스를 삭제할 때 사용 (DELETE)
Request Body를 사용하지 X
-> url에 params나 querystring으로 표시
[ HTTP 응답 상태 코드 ]
: 잘 설계된 REST API는 URI뿐만 아니라 Response까지 명확해야 한다
- 성공
[ 200 ] : 클라이언트의 요청을 정상적으로 수행함
[ 201 ] : 클라이언트의 리소스 생성 요청을 성공적으로 수행
- 리다이렉션 메시지
[ 301 ] : 클라이언트가 요청한 리소스의 URI가 변경되었을 때 반환
(Location header에 변경된 URI를 적어 줘야 한다)
[ 304 ] : 캐시 목적으로 사용 / 해당 요청의 응답이 수정되지 않음을 의미
- 클라이언트 에러 응답
[ 400 ] : 클라이언트의 요청이 부적절한 경우 사용
[ 401 ] : 클라이언트가 인증되지 않은 상태에서 보호된 리소스에 요청 시
[ 403 ] : 유저 인증과 관련 없이, 응답하고 싶지 않은 리소스 요청 시
[ 404 ] : 사용자 요청 URI 경로가 없는 경우 (NOT FOUND!)
[ 405 ] : 클라이언트가 요청한 리소스에서는 사용 불가능한 Method 이용
- 서버 에러 응답
[ 500 ] : 서버 내부 오류
