REST 란 무엇입니까? 약간 혼동 됨

REST가 웹 서비스라고 가정했지만이 생각에 틀린 것 같습니다. 그래서 REST는 무엇입니까?

Wikipedia를 읽었지만 여전히 머리를 감쌀 수는 없습니다. 많은 장소에서 API를 REST API라고하는 이유는 무엇입니까?

REST는 특정 웹 서비스가 아니라 상태 정보 관리를위한 설계 개념 (아키텍처)입니다. 이에 관한 논문은 Roy Thomas Fielding의 논문 (2000), "건축 스타일과 네트워크 기반 소프트웨어 아키텍처의 디자인"( Irvine의 캘리포니아 대학에서 온라인 으로 이용 가능 )이었습니다.

먼저 Ryan Tomayko의 게시물을 읽었습니다. 어떻게 아내에게 REST를 설명 했는지 ; 좋은 출발점입니다. 그런 다음 Fielding의 실제 논문을 읽으십시오. 그렇게 발전된 것도 아니고 길지도 않습니다 (6 장, 180 페이지)! (나는 당신이 짧은 학교처럼 아이들을 알고 있습니다).

편집 : REST를 설명하는 것이 무의미하다고 생각합니다. 확장 성, 가시성 (상태 비 저장) 등과 같은 개념이 너무 많아 독자가 파악해야하며,이를 이해하기위한 가장 좋은 출처는 실제 논문입니다. POST / GET 등이 아닙니다.

REST는 일반적으로 웹 애플리케이션에 사용되는 소프트웨어 디자인 패턴입니다. 평신도의 관점에서 이것은 많은 다른 프로젝트에서 일반적으로 사용되는 아이디어라는 것을 의미합니다. 대표 상태 이전을 나타냅니다 . REST의 기본 개념은 서버 측 (데이터베이스 테이블의 행에서와 같이)의 오브젝트를 작성하거나 파괴 할 수있는 자원으로 처리하는 것입니다.

REST에 대한 가장 기본적인 생각은 웹 애플리케이션의 URL을 형식화하는 방법입니다. 예를 들어, 리소스의 이름이 "게시물"인 경우 :

/posts 사용자가 표시하기 위해 모든 게시물에 액세스하는 방법입니다.

/posts/:id 사용자가 고유 한 ID를 기반으로 검색하여 개별 게시물에 액세스하고 보는 방법입니다.

/posts/new 새 게시물을 작성하기위한 양식을 표시하는 방법입니다.

POST 요청을 보내는 것은 /users실제로 데이터베이스 수준에서 새 게시물을 만드는 방법 입니다.

PUT 요청을 보내는 것은 /users/:id주어진 게시물의 속성을 업데이트하고 고유 한 ID로 다시 식별하는 방법입니다.

DELETE 요청을 보내는 것은 /users/:id주어진 게시물을 삭제하는 방법이며 다시 고유 한 ID로 식별됩니다.

내가 이해하는 것처럼 REST 패턴은 Ruby on Rails 프레임 워크에 의해 주로 대중화되어 (웹 앱용) RESTful 경로에 큰 중점을 둡니다. 그래도 나는 틀릴 수 있습니다.

나는 그것에 대해 이야기 할 자격이 없을 수도 있지만 이것이 내가 그것을 배운 방법입니다 (특히 Rails 개발을 위해).

누군가 "REST api"를 언급 할 때 일반적으로 의미하는 것은 데이터 검색을 위해 RESTful URL을 사용하는 API입니다.

REST이다 건축 양식 과 디자인 네트워크 기반 소프트웨어 아키텍처는.

REST개념을 자원이라고합니다. 자원의 표현은 상태 비 저장이어야합니다. 일부 매체 유형을 통해 표시됩니다. 미디어 유형의 몇 가지 예는 XML, JSON하고 RDF. 리소스는 구성 요소에 의해 조작됩니다. 구성 요소는 표준 유니폼 인터페이스를 통해 리소스를 요청하고 조작합니다. HTTP의 경우,이 인터페이스는 예를 들어, 표준 HTTP 작전으로 구성 GET, PUT, POST, DELETE.

RESTHTTPHTTP의 단순성과 RESTful 원칙에 대한 매우 자연스러운 매핑으로 인해 일반적으로 over 사용됩니다 . 그러나 REST는 특정 프로토콜과 관련이 없습니다.

기본 REST 원칙

클라이언트-서버 통신

클라이언트-서버 아키텍쳐는 매우 분리 된 관심사를 가지고 있습니다. RESTful 스타일로 빌드 된 모든 애플리케이션도 원칙적으로 클라이언트 서버 여야합니다.

무국적

서버에 대한 각 클라이언트 요청은 해당 상태가 완전히 표시되어야합니다. 서버는 서버 컨텍스트 또는 서버 세션 상태를 사용하지 않고 클라이언트 요청을 완전히 이해할 수 있어야합니다. 모든 상태는 클라이언트에 유지되어야합니다. 상태 비 저장 표현에 대해서는 나중에 자세히 설명하겠습니다.

캐시 가능

캐시 제약이 사용될 수 있으며, 따라서 응답 데이터가 캐시 가능 또는 캐시 불가능으로 표시 될 수있게한다. 캐시 가능으로 표시된 모든 데이터는 동일한 후속 요청에 대한 응답으로 재사용 될 수 있습니다.

균일 한 인터페이스

모든 구성 요소는 단일 통일 인터페이스를 통해 상호 작용해야합니다. 이 구성 요소를 통해 모든 구성 요소 상호 작용이 발생하므로 다른 서비스와의 상호 작용은 매우 간단합니다. 인터페이스는 동일합니다! 이것은 또한 구현 변경이 개별적으로 이루어질 수 있음을 의미합니다. 균일 한 인터페이스가 항상 변경되지 않기 때문에 이러한 변경 사항은 기본 구성 요소 상호 작용에 영향을 미치지 않습니다. 한 가지 단점은 인터페이스에 붙어 있다는 것입니다. 인터페이스를 변경하여 특정 서비스에 최적화를 제공 할 수 있다면 REST가이를 금지하므로 운이 나쁘다. 그러나 밝은면에서 REST는 웹에 최적화되어 있으므로 HTTP를 통한 REST의 놀라운 인기가 있습니다!

위의 개념은 REST의 특성을 정의하고 REST 아키텍처를 웹 서비스와 같은 다른 아키텍처와 차별화합니다. REST 서비스는 웹 서비스이지만 웹 서비스는 반드시 REST 서비스 일 필요는 없습니다.

REST 및 위의 원칙 에 대한 자세한 내용은 REST Design Principals 에서이 블로그 게시물 을 참조하십시오 .

Representational State Transfer를 나타내며 많은 것을 의미 할 수 있지만 일반적으로 API 및 응용 프로그램에 대해 이야기 할 때는 웹 서비스를 수행하거나 웹을 통해 프로그램을 대화하는 방법으로 REST에 대해 이야기하고 있습니다.

REST는 기본적으로 시스템 간 통신 방법이며 SOAP RPC가 의도 한 많은 기능을 수행하지만 SOAP는 일반적으로 연결을 만들고 인증 한 다음 연결을 통해 작업을 수행하지만 REST는 웹이 작동하는 방식과 거의 같은 방식으로 작동합니다 . URL이 있고 해당 URL을 요청하면 무언가를 얻습니다. 사람들이 웹을 가장 큰 REST 응용 프로그램으로 설명하기 때문에 혼동되기 시작하는 곳이며 기술적으로는 정확하지만 실제로는 무엇인지 설명하는 데 도움이되지 않습니다.

간단히 말해서 REST를 사용하면 웹 브라우저에서 사용하는 것과 유사한 도구를 사용하여 인터넷을 통해 두 개의 애플리케이션을 대화 할 수 있습니다. 이것은 SOAP보다 훨씬 간단하며 REST의 많은 기능은 "이렇게 복잡 할 필요는 없다"는 것이다.

읽을만한 가치 :

• 아내에게 휴식을 설명하는 방법 에게 (현재 사용 가능)
• 아키텍처 스타일 및 네트워크 기반 소프트웨어 아키텍처 디자인

http://en.wikipedia.org/wiki/Representational_State_Transfer

기본 아이디어는 서버에 지속적으로 연결하는 대신 요청을하고, 데이터를 가져오고, 사용자에게 보여 주지만, 전부는 아니고, 사용자가 더 많은 데이터를 요구하는 것을 할 때, 또는 일부를 서버로 전달하기 위해 클라이언트는 새로운 상태로 변경을 시작합니다.