RESTful API 다시 정리하기
1. 탄생 배경 :
로이 필딩이 웹 설계의 우수성에 비해 제대로 사용되지 못하는 모습에 안타까워 하며 웹의 장점을 활용할 '아키텍쳐'로써 REST를 발표
2. 구성
- 자원 : URI
- 행위 : HTTP 메서드
- 표현
3. REST 특징 6가지
- 유니폼 인터페이스 : 쉽게 말해 클라이언트의 플랫폼과 무관하며 특정 언어나 기술에 종속받지 않는다는 것.
- 예를 들어 웹 뿐 아니라 안드로이드, ios에서도 된다.
- 무상태성(stateless) : 작업을 위한 상태정보를 따로 저장하고 관리하지 않으며 들어오는 요청에만 단순히 응한다.
- 이전 작업이 뭐였는지 연결되어 되는 것이 아니라 독립적으로 움직인다.(HTTP stateless 생각해보기)
-
캐셔블 : HTTP 기존 웹 표준을 그대로 사용하기 떄문에 캐싱 기능이 적용 가능하다.
-
자체 표현 구조 : 동사(메서드) 명사(URI 약속) 가 명확히 눈에 보여 메시지만 보고도 알 수 있다.
-
클라이언트 // 서버 구조 : REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인정보) 등 직접 관리하는 구조로 각 역할이 확실히 구분, 의존성 줄어든다.
-
계층형 구조 : 추후 사용해보고 이해해보기. 아직은 어렵다.
"계층형 아키텍쳐 구조 역시 근래에 들어서 주목받기 시작하는 구조인데, 클라이언트 입장에서는 REST API 서버만 호출한다.
그러나 서버는 다중 계층으로 구성될 수 있다. 순수 비즈니스 로직을 수행하는 API 서버와 그 앞단에 사용자 인증 (Authentication), 암호화 (SSL), 로드밸런싱등을 하는 계층을 추가해서 구조상의 유연성을 둘 수 있는데, 이는 근래에 들어서 앞에서 언급한 마이크로 서비스 아키텍쳐의 api gateway나, 간단한 기능의 경우에는 HA Proxy나 Apache와 같은 Reverse Proxy를 이용해서 구현하는 경우가 많다."
출처: https://bcho.tistory.com/953 [조대협의 블로그]
4. 디자인 가이드
1. 요약 : 앞서 본 구성인 자원, 행위를 생각해보며..
- URI는 정보의 자원을 표현한다.
- 자원에 대한 행위는 HTTP 메서드로 표현한다.
- e.g 리소스 명은 동사보다는 명사를 쓴다.
DELETE /members/1
2. 주의사항 :
- /는 계층관계, 마지막엔 사용 않는다.
- -는 URI 가독성, _는 사용 않기
- 경로는 소문자 사용, 파일 확장자는 넣지 않는다.
3. 리소스 간 관계가 있을 때
GET : /users/{userid}/likes/devices (관계명이 애매하거나 구체적 표현이 필요할 때)
5. 응답 상태 코드
-
1xx : 조건부 응답(요청은 받았으며 작업은 계속 한다.)
-
2xx : 성공(이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.)
-
3xx : 리다이렉션 완료(클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다)
-
4xx : 요청 오류(4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.)
-
5xx : 서버 오류(서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다)
