Rest API

Rest API란?

REST는 ‘Representational State Transfer’의 약자로 자원을 이름으로 구분하여

해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다. 

REST는 기본적으로 웹의 기존 기술과 HTTP프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이라고 말할 수 있습니다.

 

REST 구성

• 자원(Resource) : 자언은 Data, Meta Data, HATEOAS로 나뉩니다.
• 행위(Verb) : HTTP Method로 표현됩니다.
• 표현(Representations)

REST 특징

1. Uniform Interface(유니폼 인터페이스) : 구성요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)해야합니다. 인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호 작용의 가시성이 개선되며, 구현과 서비스가 분리되므로 독립적인 진화가 가능해질 수 있습니다.
2. Stateless(무상태성) : 클라이언트와 서버의 통신에는 상태가 없어야합니다. 모든 요청은 필요한 모든 정보를 담고 있어야합니다. 요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 개선되고, task 실패시 복원이 쉬우므로 신뢰성이 개선되며, 상태를 저장할 필요가 없으므로 규모 확장성이 개선될 수 있습니다.
3. Cacheable(캐시 가능) : 캐시가 가능해야합니다. 즉, 모든 서버 응답은 캐시가 가능한지 그렇지 아닌지 알 수 있어야합니다. 효율, 규모 확장성, 사용자 입장에서의 성능이 개선됩니다.
4. Self-descriptiveness(자체 표현 구조) : REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것입니다.
5. Client -Server 구조 : 클라이언트-서버 스타일은 사용자 인터페이스에 대한 관심(concern)을 데이터 저장에 대한 관심으로부터 분리함으로써 클라이언트의 이식성과 서버의 규모확장성을 개선할 수 있습니다.
6. Layerd System(계층형 구조) : REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.

REST API 설계 가이드

1. URI는 정보의 자원을 표현해야합니다.
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현합니다.
3. URI에 HTTP Method가 들어가면 안됩니다.
4. URI에 행위에 대한 동사 표현이 들어가면 안됩니다.
5. 경로 부분 중 변하는 부분은 유일한 값으로 대체합니다.
6. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용합니다.
7. URI 마지막 문자로 슬래시(/)를 포함하지 않습니다.
8. URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 합니다.
9. 하이픈(-)은 URI 가독성을 높이는데 사용할 수 있습니다.
10. 밑줄(_)은 URI에 사용하지 않습니다.
11. URI 경로에는 소문자가 적합합니다.
12. 파일 확장자는 URI에 포함하지 않습니다. Accept header를 사용하도록 합니다.
13. 리소스 간에 연관 관계가 있는 경우 다음과 같은 방법으로 표현합니다.
14. 자원을 표현하는 컬렉션과 도큐먼트

HTTP 응답 상태 코드

 

HATEOAS란?

'Htpermedia As The Engine Of Application State'의 약자입니다.

DATA와 함꼐 관련된 URL 정보를 제공하는 것을 HATEOAS라고 말합니다.

 

https://www.boostcourse.org/web326/lecture/58986/?isDesc=false

웹 백엔드