[Day2] REST API
PART 1 |
REST |
- "Representational State Transfer"의 약자
- 자원을 이름으로 구분하고 해당 자원의 상태를 주고 받는 모든 것
- 일반적으로 좁은 의미로 HTTP를 통해 CRUD를 실행하는 API
- HTTP기반으로 필요한 자원에 접근하는 방식을 정해놓은 아키텍처 스타일(제약 조건의 집합)
- 웹에 존재하는 모든 자원(이미지, 동영상, DB자원)에 고유한 URI를 부여해 활용
2# REST 특징(제약조건)
- Server-Client 구조
- 자원(Resource)이 있는 쪽이 Server, 요청을 하는 쪽이 해당 서버에 대한 Client
- 모든 통신은 클라이언트-서버간의 일대일로 연결
- 서버 : 클라이언트의 상태를 신경 쓰지 않고 제공한 인터페이스에 대한 처리만 담당하여 요청이 들어올 때 그에 맞는 응답을 제공
- 클라이언트 : 서버의 자세한 사항에 대해 신경 쓸 필요 없이 제공되는 인터페이스를 통해 접근하여 응답을 받음. 자신의 Context를 관리
=> 역할이 각각 확실하게 구분되어, 개발에 있어서 의존성이 줄어듦 - Stateless(무상태)
- 'Server'는 각각의 요청을 완전히 별개의 것으로 인식하고 처리
=>Server의 처리방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아짐 - Client의 Context를 Server에 저장하지 않음.
=> 서비스의 자유도가 높아지고 구현이 단순해짐 - Cacheable(캐시 처리 가능)
- 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구됨
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용
=> 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜젝션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다. - Layered System(계층화)
- Client는 REST API Server만 호출
- REST Server는 다중 계층으로 구성될 수 있음
ex) 순수 비지니스 로직을 수행하는 API서버와 그 앞단에 사용자 인증, 암호화 등을 하는 계층을 추가해서 구조상의 유연성을 둘 수 있음 - Code-On-Demand(optional)
- 서버로부터 스크립트를 받아서 클라이언트에서 실행(ex. Html의 javascript)
- 서버에서 제공되는 코드를 실행해야 하기 때문에 보안 문제를 야기할 수 있음
- Uniform Interface(인터페이스 일관성)
- 자원은 유일하게 식별 가능해야함
- HTTP Method로 표현을 담아야 함
- 메세지는 스스로를 설명(self-descriptive)해야함
- 하이퍼링크를 통해 애플리케이션의 상태가 전이(HATEOAS)되어야 함
- URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행
- HTTP표준만 따른다면 어떠한 기술이든 사용이 가능
3# RESTful
- REST의 비공식적 구현 가이드
- REST의 특징을 모두 만족하는 것
PART 2 |
REST API |
- REST 기반으로 서비스 API를 구현한 것
- HTTP 통신에서 어떤 자원에 대한 CRUD요청을 Resource와 Method로 구현하여 특정한 형태로 전달하는 방식
2# REST API의 특징 -> REST의 특징
- 사내 시스템들도 REST기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있음
- HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있음
3# REST API의 구성요소
- 자원(Resource) - URI : 서버는 Unique한 ID를 가지는 Resource를 가지고 있으며, 클라이언트는 이러한 Resource에 요청을 보냄. REST에서 자원에 접근할 때 URI로 하게 됨
- 행위(Verb) - HTTP Method : 서버에 요청을 보내기 위한 방식으로 GET, POST, PUT, DELETE가 있음
METHOD |
역할 |
POST |
해당 URI를 요청하면 리소스 생성 |
GET |
해당 리소스를 조회하고 해당 도뮤먼트에 대한 자세한 정보를 가져옴 |
PUT |
해당 리소스 수정 |
DELETE |
해당 리소스 삭제 |
- 표현(Representation) : 클라이언트와 서버가 데이터를 서로 주고받는 형태로 json, xml, text, rss 등이 있음
4# REST API 디자인 가이드
4-1. REST API 중심 규칙
1. URI는 정보의 자원을 표현해야 한다.(리소스명은 동사보다는 명사를 사용)
ex. 회원정보를 가져오는 URI
GET /members/delete/1(x)
=> URI는 자원을 표현하는데 중점을 두어야 함.(delete와 같은 행위에 대한 표현이 들어가면 x)
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
DELETE /members/1(o)
=> URI는 자원을 표현하는 데에 집중하고 행위에 대한 정의는 HTTP METHOD를 통해 하는 것이 REST한 API를 설계하는 중심 규칙
[참고] * URL(Uniform Resource Locator) : 네트워크 상에서 자원이 어디 있는지를 알려주기 위한 규약 * URI(Uniform Resource Identifier) : 인터넷에 있는 자원을 나타내는 유일한 주소 ex1. http://test.com/work/sample.pdf : test.com서버에서 work 폴더안의 sample.pdf를 요청하는 URL이면서 URI ex2. https://www.google.co.kr/search?q=uri => https://www.google.co.kr/search : URL => https://www.google.co.kr/search?q=uri : URI이지만 URL은 x (q의 값에 따라 여러가지 결과값을 가져올 수 있음) * URI = URL+URN |
4-2. URI 설계 시 주의할 점
1) 슬래시 구분자(/)는 계층관계를 나타내는 데 사용
2) URI 마지막 문자로 슬래시를 포함하지 않음
3) 하이픈(-)은 가독성을 높이는데 사용
4) 밑줄(_)은 URI 에 사용하지 않음
5) URI경로에는 소문자가 적합
6) 파일 확장자는 URI에 포함시키지 않음
5# HTTP status Code(HTTP 응답 상태 코드)
상태코드 |
|
200 |
클라이언트의 요청을 정상적으로 수행함 |
201 |
클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시) |
상태코드 |
|
400 |
클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드 |
401 |
클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용하는 응답 코드 |
403 |
유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드 |
404 | API요청 URL이 잘못되었을 경우 사용하는 응답 코드(API 없음) |
405 |
클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드 |
상태코드 |
|
301 |
클라이언트가 요청한 릴소스에 대한 URI가 변경 되었을 때 사용하는 응답 코드 |
500 |
서버에 문제가 있을 경우 사용하는 응답 코드 |
6# 회원가입 예제
|
method |
url | 이유 |
회원가입 |
POST |
https://api.whosfan.com/join | create |
로그인 |
POST |
https://api.whosfan.com/login | get 방식으로 할 경우 보안 문제 발생 |
회원정보 호출 |
GET |
https://api.whosfan.com/users/{id} | select |
회원정보 변경 |
PUT |
https://api.whosfan.com/users/{id} | update |
로그아웃 |
POST |
https://api.whosfan.com/users/{id}/logout | 데이터 베이스가 변경됨 |
탈퇴 |
DELETE |
https://api.whosfan.com/users/{id} | delete |
[Reference] https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html https://www.a-mean-blog.com/ko/blog/%ED%86%A0%EB%A7%89%EA%B8%80/_/REST%EC%99%80-RESTful-API https://jeong-pro.tistory.com/180 https://mangkyu.tistory.com/46 https://ijbgo.tistory.com/20 https://velog.io/@zansol/%EB%B9%84%EA%B3%B5%EA%B0%9C-REST-API https://meetup.toast.com/posts/92 https://jjunii486.tistory.com/28 http://sunychoi.github.io/java/2015/04/27/uri-url.html https://medium.com/@dydrlaks/rest-api-3e424716bab
https://swalloow.github.io/open-api-guide https://itstory.tk/entry/%EB%8D%94-%EB%82%98%EC%9D%80-RESTful-API%EB%A5%BC-%EC%84%A4%EA%B3%84%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%B5%9C%EA%B3%A0%EC%9D%98-10%EA%B0%80%EC%A7%80-%EC%97%B0%EC%8A%B5%EB%B0%A9%EB%B2%95