REST API란

API 란?

Application Programming Interface
운영 체제나 프로그래밍 언어, 응용프로그램이 제공하는 기능을 그 기능을 사용하고자 하는 응용 프로그램에서 사용하고 제어할 수 있도록 만든 인터페이스
API를 사용하면 내부 구현 로직을 알지 못해도 정의되어 있는 기능을 쉽게 사용할 수 있습니다.

클라이언트는 서버의 구성과 상관없이 REST API 서버로 요청을 보낼 수 있습니다.
- 서버의 구조가 변경되더라도 클라이언트는 영향을 받지 않습니다.
서버는 다중 계층으로 구성될 수 있습니다.
- 대량의 접속을 처리하기 위한 로드밸런싱이나 보안, 캐시 등의 계층을 추가하더라도 클라이언트는 이전과 동일한 요청을 보내면 동일한 결과값을 받습니다.

인터페이스 일관성
정보가 표준 형식으로 전송되기 위해 구성 요소간 통합 인터페이스를 제공해야합니다.
- 대부분이 HTTP를 사용하기 때문에 HTTP 프로토콜을 따르는 모든 플랫폼에서 사용가능하게끔 HTTP 프로토콜을 준수하여 설계해야합니다.
  - HTTP 표준인 URL과 응답코드 , Request-Response Method 등을 사용합니다.
Uniform Interface의 4가지 조건
- Identification of resources
  - 리소스가 URI로 식별이 되는지
- Manipulation of resources through representations
  - 서버가 클라이언트에서 이해할 수 있는 형식으로 응답하는지
    - ex. JSON 으로 응답
- Self-descriptive messages
  - 메시지의 모든 요소가 메시지만 보고 그 뜻을 알 수 있는지
- Hypermedia as the engine of application state (HATEOAS)
  - 애플리케이션 상태를 Hyperlink를 이용해서 전이할 수 있는지
  - 어느 한 자원을 조회하면 그 자원을 통해 접근 가능한 자원들을 하이퍼링크를 통해 알려주어야 한다는 것을 의미합니다.

💡 최근의 REST API는 Self-descriptive messages 와 HATEOAS가 잘지켜지지 않는다고 합니다.
아래의 링크를 통해서 준수하는 법을 공부하도록 합시다.

웹 기반의 REST API를 설계한 경우에는 URI를 통해 자원을 표현해야 합니다.
- https://dokuny.com/member/123
  - Resource : member
  - Resource id : 123
자원에 대한 조작은 HTTP Method(CRUD)를 통해 표현해야 합니다.
- URI에 행위가 들어가면 안됩니다.
  - https://dokuny.com/register/user 이런식으로 행위가 들어가도록 작성하면 안됩니다.
- HEADER를 통해 CRUD를 표현하여 동작을 요청해야 합니다.
메세지를 통한 리소스 조작
- HEADER를 통해 content-type을 지정하여 데이터를 전달
  - REST의 Self-descriptive messages와 HATEOS와 연관이 깊습니다.
  - 구체적인 정보를 같이 전달해야 서버나 유저가 인식을 하고 사용할 수 있습니다.
- 대표적 형식으로는 HTML, XML, JSON , TEXT 등이 있습니다.
URI에는 소문자를 사용
Resource의 이름이나 URI가 길어질 경우 하이픈(-)을 통해 가독성을 높임
언더바(_) 사용 금지
파일 확장자를 표현하지 않음