REST API 알아보기

드코딩·2024년 7월 22일

API RESR API REST

Rest API 규칙

REST API를 만들고 싶은데 내가 명세한 API가 팀원이 작성한 API를 리뷰할 때 이게 Rest한게 맞나?
맞다면 왜? 아니라면 왜 아닌지 구분하는 것은 어렵다.

REST API와 비교되는 다른 SOAP API가 존재하는데

REST는 SOAP과 비교하면 1. 단순하다. 2. 규칙이 적다. 3. 쉽다는 장점이 있다.

Rest API는 HTTP 요청을 사용하여 웹 서비스에 접근할 수 있도록 하는 인터페이스이다.

Rest API? Restful API? Rest API, Restful API 이 두 가지 단어로 많이 접했을 것이다. 보통 혼용해서 많이 사용하지만
사실은 둘이 조금 다르다. Rest 설계 원칙이 존재하는데 이 설계원칙을 따른 정도에 따라 Restful API,
Rest API로 나뉜다.
Rest API : 설계원칙을 엄격하게 지켜서 작성한 API를 Rest API : Rest 원칙을 따른 경우
- 엄격의 기준은 뭘까? Rest의 기본 개념은 따르지만, 완전히 준수하지 못한 경우라고 한다.
  그럼 Restful API 매우 엄격하게 모두 준수한 것을 말할 것 같다. 따라서 최근에는 많은 개발자가 자신은 Restful API를 작성했다고 하는데 사실 그것은
  Restful 보다는 → Rest API인 경우가 많다.

사실 REST API는 로이 필딩이라는 분이 발표한 논문의 내용이다.
해당 논문에서는 아래와 같은 원칙을 제시한다.

REST의 6가지 설계 원칙

일관된 인터페이스

URI로 지정한 자원 (resource)에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는
구조적 스타일을 말한다.
클라이언트 - 서버

클라이언트와 서버를 독립적으로 분리되어 구성되어야 한다.
각각 별도로 개발되고 대체 가능하도록 유지해야한다.
무상태

작업에 대한 요청의 상태 정보를 저장하거나 관리 하지 않음

세션, 인증, 쿠키 등의 정보는 별도로 저장하기 때문에 요청에 대한 어떠한 상태 정보를
저장하지 않고 단순 처리할 수 있어야한다.이를 위해 모든 요청에는 필요한 모든 정보가 포함되어야 한다.
캐시의 가능

서버는 캐시 가능 여부를 제공해야 함.
캐시가 가능 할 경우 클라이언트 응답 데이터를 재 사용 하여 성능과 서버의 가용성을 올릴 수 있다.
- 어떻게 캐시 가능여부를 알릴 수 있지?
계층화된 시스템

계층화된 구조로 구성되어야 한다. 각 계층 자신이 통신하는 컴포넌트 외 다른 계층에 대한 정보를
얻을 수 없도록 분리되어야 한다.
주문형 코드(선택 사항)

클라이언트는 서버로부터 실행시킬 수 있는 로직을 다운 받아 기능을 확장시킬 수 있다.
이를 통해 클라이언트가 사전에 구현해야 하는 기능을 수를 줄여 간소화 시킬 수 있다.

어떻게 Rest API를 따르고 있지?

내가 생각하는

Rest API는 명세서왕 Response를 보고 클라이언트가 모든 것을 이해할 수 있어야한다.

고 생각한다.
예를 들어 수정 작업이 일어날건지 , 이 데이터는 무엇을 요구하는지
어떠한 미디어 타입을 원하는지 등등

아래의 규칙들은 Rest API를 작성하기 위해서 많이들 사용하고 있는 방법들이다.
하지만 이것을 지킨다고 완전한 Rest API가 되는 것은 아니다.

계층관계를 나타내기위해 /를 사용
자원의 필터링을 위해 쿼리파라미터를 사용
CRUD 함수명은 사용하지 않는다.
소문자를 사용
파일의 확장자는 사용하지 않음
자원을 명사로 나타내야한다.

로이 필딩(REST 저자) 말하는 REST API를 만들기!

많은 사람이 Rest API를 주장하지만, 원작자는 만족스러워하지 않는다고 한다.

여기부터 내용은 아래의 링크의 영상을 참고하여 정리한 내용이다.

🔗https://www.youtube.com/watch?v=RP_f5dMoHFc&t=1163s

MS REST API Guilelines (2016)

마이크로소프트에서 Rest API의 가이드라인을 제시했다.

uri 는 https://{serviceRoot}/{collection}/{id} 형식이어야 한다.
GET, PUT, DELET , POST , HEAD, PATCH, OPTIONS를 지원해야 한다.
등등

하지만 Rest API 로이필딩은 이것을 보고 REST API가 아니라고 했다고 한다.

뭐가 문제일까?

REST : 분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일(제약조건의 집합)
여기서 말하는 아키텍쳐 스타일은 위에서 정리한 6가지인데 여기서 일관된 인터페이스
이 부분은 4가지고 세분되어있다.

보통 개발자들이 4가지 중 2가지를 지키지 못한다고 한다.

못 지키고 있는 2가지

응답으로 제공된 JSON

이렇게 된 경우 클라이언트가 응답을 받고 해석해야 하는데, 어떤 문법으로 작성되었는지 모른다..
일단 Content-Type이 명시되어 있지 않기 때문에 클라이언트는 해석할 수 없다.
그렇다면 컨텐츠 타입만 명시하면 되는 걸까? 그것도 아니다!

application/json 타입인데 json-patch라는 명세가 있는데 거기 명세표를 본다면 너는
이해할 수 있어.. 라고 의미하기 때문에 메시지만을 보고 스스로를 증명할 수 있는 조건을 만족한다.

애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다. (HATEOAS)
클라이언트의 애플리케이션 상태가 바뀌는 것은 Hyperlink를 통해서 바뀌어야 한다는 말이다.
예를 들어서 게시판을 제공하는 사이트가 있을때 사용자의 흐름은

이렇게 페이지가 전환될 때 응답으로 보일 페이지의 hyperlink를 제공하고 이를 통해서 화면이 이동되어야 한다.

HTML의 경우
```
 HTTP/1.1 200 OK
 Contemt-Type: text/html

 <html>
 <head></head>
 <body><a href="/test">test</a></body>
 </html>
```
<a> 태그를 통해 링크 제공
JSON의 경우
```
   HTTP/1.1 200 OK
   Contemt-Type: application/json
   Link</article/1>; rel="previous"
   Link</article/3>; rel="next";
   {
        "title": "The Second article",
        "contents": "abcde"
    }
```
header를 통해서 이전글과, 다음금 uri를 표현 해주어 HATEOAS를 만족한다.

왜 지켜야 하는데?

독립적 진화 서버와 클라이언트가 각각 독립적으로 진화해야 한다는 말이다.
구체적으로는 서버가 기능이 바뀐다고 생각해보자, 새로운 API가 추가되고 기존 API가 수정, 삭제된 경우
이럴 때 클라이언트가 업데이트가 되지 않아도 된다. 이것이 독립적인 진화이다. 이를 위해서는 일관된 인터페이스를 지켜야 한다.
REST가 웹의 독립적 진화에 도움을 주었나?
- Host 헤더에 추가
- 길이 제한을 다루는 방법을 명시
- URI에서 리소스의 정의가 추상적으로 변경됨 : “식별하고자 하는 무언가”

이렇게 지키는 것이 REST API라고 한다고 한다. 단순하고 쉽다고 표현했는데 사실 완전한 REST 조건을 지키기 위해서는 힘들고 복잡한 과정을 가져야 한다.

느낀 점

영상을 보고 Rest API를 만들기 위해서는 생각보다 JSON 타입으로 이를 만족하기 위해서는 좀 더 번거로운 작업이 필요하다고 생각했다. 하지만 영상에서 지적해준 self-descript message, HATEOAS를 지킨다면 클라이언트 입장에서 수월하고 독립적인 관계가 될 수 있다는 것에 공감된다.

최대한 Rest API 기본부터 지키면서 영상에서 언급한 부분까지 지킬 수 있도록 노력해야겠다.

⭐틀린 내용 수정,지적은 언제나 환영합니다.⭐

드코딩

이전 포스트

[Spring] Dependencies

다음 포스트