Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

REST API 설계를 위한 HATEOUS 지원 #17

Open
yanghun0070 opened this issue Apr 5, 2020 · 0 comments
Open

REST API 설계를 위한 HATEOUS 지원 #17

yanghun0070 opened this issue Apr 5, 2020 · 0 comments
Labels
documentation Improvements or additions to documentation question Further information is requested wiki wiki

Comments

@yanghun0070
Copy link
Owner

yanghun0070 commented Apr 5, 2020 •
edited
Loading

REST 란?

  • Client-server
  • stateless
  • cache
  • Uniform interface -> 잘 만족 못한다.
  • Layered system
  • Code on demand (optional) -> 서버에서 코드를 서버로 보내서 실행시킬 수 있어야 한다. ex)javascript

Uniform interface 란?

  • Identification of resources : 리소스가 URL로 식별되어야 한다.
  • Manipulation of resources through representations : HTTP Message 표현을 담아서 보내야 한다.
  • Self-descriptive messages : 메시지가 스스로를 설명해야한다.
  GET / HTTP/1.1
  Host : www.example.org // 목적지가 빠져있다.
    

  HTTP/1.1 200 OK 
  [{ “op”: “remove”, “path”: “/a/b/c” }] // Client 가 해독해야하는데, 어떤 문법인지 알 수가 없다.
 Content-Type : application/json // op, path 뜻이 뭐지? Message 내용만으로 해독하지 못한다.
  • Hypermedia as the engine of application state (HATEOUS)
  • Application 상태의 전이
  • 페이지에 있던 링크를 따라가며 정의했기 때문에 HATEOUS
  • HATEOUS : 하이퍼링크를 통한 전의
HTTP/1.1 200 OK
Content Type: text/html

<html>
<head></head>
<body><a href=“/test”>test</a></body>
</html>

a tag를 통해 하이퍼링크를 통해 가므로, HATEOUS를 만족한다.

Json 으로도 만족가능할 수 있지만, self-descriptive messages : title, contents 뭔지 알 수가 없다.

HTTP/1.1 200 OK
Content Type : application/json
Link </articles/1> rel=“previous”
        </articles/3> rel=“next”
{
    “title”: “The second article”,
    “contents”: “Blah Blah..”
}

Uniform interface 를 해야되는 이유?

독립적 진화

  • 서버와 클라이언트가 각각 독립적으로 진화한다.
  • 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
  • REST를 만들게 된 계기: “How do I improve HTTP without breaking the Web"

REST 가 지켜지고 있는가?

  • 웹 페이지를 변경했다고 웹 브라우저를 업데이트 할 필요없다.
  • 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요없다.
  • HTTP 명세가 변경되어도 웹은 잘 동작한다.
  • HTML 명세가 변경되어도 웹은 잘 동작한다.

REST API 는?
REST 아키텍처 스타일을 지켜야 한다.
하이퍼텍스트를 포함한 self-descriptive 한 메시지의 uniform interface를 통해 리소스에 접근하는 API

JSON

즉, HATEOUS 는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.

특히 PUT, DELETE 메소드로는 WebDAV 서비스와 함께 원격지 웹 서버에 파일을 생성하거나 삭제하는 FTP와 >> 유사한 기능을 구현할 수 있다. 이는 웹 콘텐츠 디렉터리 및 httpext.dll 권한 할당 오류로 인해 인증 절차 없이 원격지 서버에 파일을 생성하거나 삭제할 수 있다.

http://coashanee5.blogspot.com/2017/03/http.html?m=1
@yanghun0070 yanghun0070 added question Further information is requested documentation Improvements or additions to documentation labels Apr 5, 2020
@yanghun0070 yanghun0070 added the wiki wiki label Jun 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation Improvements or additions to documentation question Further information is requested wiki wiki
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@yanghun0070