API(Application Programming Interface)
in Web Dev on Java Spring
- 응용 프로그램에서 사용할 수 있게 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
- 주로 파일 제어, 창 제어, 화상 처리, 문자 제어를 위한 인터페이스를 제공
RestAPI(REpresentational State Transfer API)
핵심 컨텐츠 및 기능을 외부 사이트에서 활용할 수 있게 제공되는 인터페이스
웹뿐 아니라 앱 등 다양한 클라이언트의 등장으로 REST API가 각광받기 시작
제약조건은 다음과 같다.
1. client-server 2. stateless 3. cache 4. layered system 5. uniform interface 6. code-on-demand (optional)1~4번은 HTTP 프로토콜을 사용하면 쉽게 구현 가능하다. 그러나 5번, uniform interface는 어렵다.
Client-Server
- REST 서버는 API를 제공하고, 클라이언트는 사용자 인증이나 세션, 로그인 정보등의 컨텍스트를 직접 관리하므로 각자의 역할이 명확히 구분돼서 서로 의존성이 줄어든다.
Stateless
- 작업을 위한 상태정보를 따로 저장하지 않는다. 세션 정보나 쿠키 정보에서 자유롭고, 들어오는 요청만 처리해주면된다.
Cacheable
- HTTP 의 기존 웹표준을 그대로 사용하기 때문에, HTTP가 가진 캐싱 기능 적용이 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능
Self-descriptiveness
- REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다는 것
Layerd System
- REST 서버는 다중 계층으로 구성될 수 있고 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 줄 수 있고, PROXY, 게이트 웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.
Uniform Interface
- 리소스가 URI로 식별돼야함.
- 리소스 생성, 수정, 추가할 때 HTTP 메시지에 표현해서 전송해야함.
- 애플리케이션의 상태는 Hyperlink 를 이용해 전이돼야함.(HATEOAS)
이 중에, 메세지가 스스로 설명할 수 있어야 하는 부분과 HATEOAS를 지원하는게 웹과는 다르게 API로는 쉽지않다.
WEB API
URI는 정보의 자원을 표현해야한다.
자원에 대한 행위는 HTTP Method로 표현한다.
출처- https://meetup.toast.com/posts/92
DO
GET /members/1
POST /members
PUT /members/1
DELETE /members/1
DON’T
GET /members/get/1
GET /members/add
GET /members/update/1
GET /members/del/1
URI 표현 규칙
- 슬래시 구분자는 계층을 나타낼 때 사용
- URI 마지막 문자로 슬래시 구분자(/)를 포함하지 않음
- 하이픈(-)은 가독성을 높일 때 사용
- 언더바(_)는 사용하지 않음
- URI 경로는 소문자만 사용
- 파일 확장자는 URI에 포함시키지 않고, Accept Header를 사용한다.
상태코드
200 : 클라이언트의 요청을 정상적으로 수행
201 : 클라이언트가 어떤 리소스 생성을 요청, 해당 리소스가 성공적으로 생성 (POST 작업 시)
400 : 클라이언트 요청이 부적절 할 때
401 : 클라이언트가 인증하지 않은 상태에서 보호된 리소스 요청시
403 : 응답하고 싶지 않은 리소스를 클라이언트가 요청을 때 사용하는 응답코드
405 : 클라이언트가 요청한 리소스에서 사용 불가능한 METHOD를 이용했을 경우.
301 : 클라이언트가 요청한 리소스에 대한 URI가 변경됐을 때
500 : 서버에 문제가 있을 경우`
- 403을 보다는 400이나 404를 사용할 것을 권장한다. 403 자체가 리소스가 존재함을 의미하기 때문이다.
