REST API

 

 

내가 이해한 REST 이게 맞나 ? 

 

요즘 아니 언제부터인가 REST라는 말들이 많이 나오기 시작했다. 단어가 생소한 나는 검색을 해봐도 도대체 이게 뭐지?? 라는 의문만 내놓게 되었는데 자바 웹 프로그래밍을 공부하다보니 프론트 엔드에서 URI를 통한 API 호출 그리고 ajax를 통해 JSON 형태로 값을 받아오는 부분을 알게 되었다. 

토이 프로젝트로 해당 부분을 할때 URI를 던져줬던 부분이 이제와 생각해보면 REST 방식이라고 생각된다. 근데 왜 몰랐을까 개념이 제대로 잡히지 않아서였던것 같다. 지금도 계속 글을 쓰면서 정말 이것이 맞는건가 ? 의문이 드는데 조만간 실습을 포함한 포스팅을 할것이다. 

 

 

 

먼저 유튜브 백기선님의 영상을 통해 REST에 대해 관심을 갖게 되었다. 

https://www.youtube.com/watch?v=L_cOsweHGWc

 

그리고 항상 헷갈렸던 부분 URI를 통해 resource(자원)을 구분한다는건 알겠다만 구분한다는것이 URI로 자원도 같이 보낼 수 있는건가??에 대한 명확한 이해가 필요했다. 

 

그래서 REST 특징 중 한가지를 알게 되었다. 

 

출처 :
https://berrrrr.github.io/programming/2019/11/03/restapi-uniform-interface/
https://programmer7895.tistory.com/28

 

Uniform Interface(일관된 인터페이스)

- URL로 지정된 리소스에 대한 조작을 통일하고 한정된 인터페이스로 수행하는 아키텍처 스타일

- 요청을 하는 Client가 플랫폼(Android, Ios, Jsp 등) 에 무관하며, 특정 언어나 기술에 종속받지 않는 특징을 의미한다.

- 이러한 특징 덕분에 Rest API는 HTTP를 사용하는 모든 플랫폼에서 요청가능하며, Loosely Coupling(느슨한 결함) 형태를 갖게 되었다.

 

* REST API에 관한 정의를 이해해보자

 

 

1) URL과 한정된 인터페이스

- 예전에는 param을 통해 해당 resource(자원)에 접근을 할 수 있었다고 한다. 예를 들어 “localhost:8080/user=admin“ 이라는 URI를 통해 관리자 모드로 들어갈 수 있었다. 하나의 param이라면 상관이 없지만, 상황에 따라서는 URI 주소가 길어지는 염려가 생긴가. REST API 특징 중에 하나가 URL을 쓰는 동시에 한정된 인터페이스로써 사용하면 굳이 주소를 길게 적을 필요없이 한정된 자원으로도 해당 resource를 접근할 수 있는 장점을 가지게 된다.

 

(로컬에서 실행한 URI로 예를 들었다.)

 

예전 URI	https://localhost:8080/auth=admin
REST 적용 URL	https://localhost:8080/adimn

 

** 오호 뭔가 이해가 간다.

 

2) 한정된 인터페이스의 의미

- 한정된 인터페이스란 무엇일까

Resource	GET	PUT	POST	DELETE
https://localhost:8080/adimn	관리자 페이지 조회	관리자 페이지 수정	관리자 페이지 생성	관리자 페이지 삭제

 

- GET, PUT, POST, DELETE 이 4가지 인터페이스로 한정지어서 해당하는 Resource를 접근한다. 다양한 방법으로 설명이 될 수 있는 Representation을 가진다.

- 다시 말해서 resource 자체를 전송하는게 아니라 resource 표현을 전송한다고 생각하면 될 거 같다.

- 이 방식을 사용하게 되면 URL 주소 길이가 짧아지고 하나의 URL이 많은 Representation을 나타낼 수 있는 장점을 가지게 된다.

 

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다. 

 

출처 : http://www.incodom.kr/REST

 - 매우 설명이 좋다.

 

---

리소스를 요청할 때 서버는 리소스를 표현하여 응답한다. 이 표현은 클라이언트가 이해하고 조작할 수 있는 형식으로 리소스의 현재 상태를 캡처한다. 사실상, 표현은 그러한 바이트를 설명하는 메타데이터와 함께 바이트의 순서다. 이 메타데이터는 표현의 미디어 유형으로 알려져 있다. 대표적인 API 예로는 HTML, JSON, XML이 있다. 서버가 자원의 표현을 보내기 때문에 클라이언트가 클라이언트의 요구에 맞는 특정 표현을 요청할 수 있다. 예를 들어 클라이언트는 리소스의 JSON 표현 또는 리소스의 XML 표현을 요청할 수 있다. 서버는 그렇게 할 수 있는 경우 이 표현을 제공할 수 있다. 이 개념을 콘텐츠 협상이라고 한다. API에서 콘텐츠 협상을 사용하여 여러 클라이언트가 동일한 URL에서 다른 리소스 표현에 액세스할 수 있도록 할 수 있다.

 

 

GET /orders/12345
Accept : text/plain

위와 같이 요청시 -> plain test로 response(응답)

 

GET /orders/12345
Accept : application/json

위와 같이 요청시 -> JSON으로 response

 

 

self-descriptive message

클라이언트가 resource를 가지고 어떤 일을 수행할 때 필요한 모든 데이터가 응답되어야 한다. 보통 안에 profile(docs) 링크를 명시하는 식으로 구현한다.

 

Hypermedia As The Engine Of Application State(HATEOAS)

거의 모든 REST API에서 지키지 못한다. 애플리케이션의 상태가 하이퍼링크를 통해서 항상 전이가 되어야 한다. 스프링에서는 spring-boot-hateoas 패키지로 편하게 구현이 가능하다.

 

 

github API를 보면 (https://developer.github.com/) HATEOAS를 가장 잘 지키고 있다.

 

적용예시

{
  "timeline_url": "https://github.com/timeline",
  "user_url": "https://github.com/{user}",
  "current_user_public_url": "https://github.com/octocat",
  "current_user_url": "https://github.com/octocat.private?token=abc123",
  "current_user_actor_url": "https://github.com/octocat.private.actor?token=abc123",
  "current_user_organization_url": "",
  "current_user_organization_urls": [
    "https://github.com/organizations/github/octocat.private.atom?token=abc123"
  ],
  "security_advisories_url": "https://github.com/security-advisories",
  "_links": {
    "timeline": {
      "href": "https://github.com/timeline",
      "type": "application/atom+xml"
    },
    "user": {
      "href": "https://github.com/{user}",
      "type": "application/atom+xml"
    },
    "current_user_public": {
      "href": "https://github.com/octocat",
      "type": "application/atom+xml"
    },
    "current_user": {
      "href": "https://github.com/octocat.private?token=abc123",
      "type": "application/atom+xml"
    },
    "current_user_actor": {
      "href": "https://github.com/octocat.private.actor?token=abc123",
      "type": "application/atom+xml"
    },
    "current_user_organization": {
      "href": "",
      "type": ""
    },
    "current_user_organizations": [
      {
        "href": "https://github.com/organizations/github/octocat.private.atom?token=abc123",
        "type": "application/atom+xml"
      }
    ],
    "security_advisories": {
      "href": "https://github.com/security-advisories",
      "type": "application/atom+xml"
    }
  }
}

 

---

 

https://deview.kr/2017/schedule/212 에서 나온 글이다. (2017년도 기준)

 

- REST API를 온전히 구현하는 것은 어렵다고 한다. HTTP API들 중에서 REST API라고 할 수 있는 것은 사실상 많지 않다. REST를 구성하는 스타일 중 Uniform Interface 스타일의 제약조건들이 잘 지켜지지 않고 있기 때문이다.

 

- Uniform Interface(일관된 인터페이스)는 언제 어디서나 한결같을 것을 요구한다. 인터넷을 통해 누구나 사용할 수 있도록 공개된 REST API라면 오직 단 하나의 진입점 URI만 알면 그 API를 그대로 사용할 수 있어야 한다. 또 서버가 변경되었다고 클라이언트를 교체해야 하는 일도 없어야 한다.

 

 

http://slides.com/eungjun/rest#/ 의 영상을 보는 것을 추천한다.

 

 

 

개념적인 내용을 썼는데 나도 아직 감이 안와서 다음 포스팅은 직접 자바와 스프링을 통해 실습한 것을 올릴 예정이다.

모든 개발자 취준생들 화이팅 !!! 열심히 공부합시다