[Day2] REST API

---

PART 1

REST

    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

    1# 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