HTTP와 REST의 차이점은 무엇입니까?

REST와 SOAP의 차이점에 대해 많이 읽은 후 REST가 HTTP의 또 다른 단어라는 인상을 받았습니다. 누군가 REST가 HTTP에 추가하는 기능을 설명 할 수 있습니까?

참고 : REST와 SOAP의 비교를 찾고 있지 않습니다.

업데이트 : 답변 주셔서 감사합니다. 이제 REST는 HTTP 사용 방법에 대한 일련의 규칙이라는 것이 분명해졌습니다. 그러므로 나는 이 협약의 장점이 무엇인지에 대한 후속 조치를 게시했습니다 .

참고 : 이제 REST의 의미를 파악합니다. 로 에밀 이바노프 발언, REST 수단은 HTTP가 될 운명이야 방법을 사용하여. 그러나 나는 이것이 그 자체의 용어가 가치가 있는지 확실하지 않으며, 나는 그 주위에 과대 광고를하지 않습니다.

아니, REST는 방식이다 HTTP가 되어야한다 사용 .

오늘날 우리는 아주 작은 HTTP 프로토콜의 방법, 즉 GETand 만 사용합니다 POST. REST 방법은 모든 프로토콜 메소드를 사용하는 것입니다.

예를 들어 REST는 DELETEURI 뒤에서 문서 (파일, 상태 등)를 지우는 사용법을 지시하는 반면, HTTP의 경우 와 같은 GET또는 POST쿼리를 잘못 사용합니다 ...product/?delete_id=22.

HTTP는 통신에 사용되는 프로토콜로, 일반적으로 인터넷 리소스 또는 웹 브라우저 클라이언트와의 응용 프로그램과 통신하는 데 사용됩니다.

REST는 애플리케이션을 설계 할 때 사용하는 주요 개념이 자원이라는 것을 의미합니다. 수행하려는 각 조치에 대해 일반적으로 CRUD 조작 만 수행하는 자원을 정의해야합니다. 이는 간단한 작업입니다. 따라서 4 개의 CRUD 연산에 대해 HTTP 프로토콜에 사용되는 4 개의 동사를 사용하는 것이 매우 편리합니다 (읽기, 읽기, POST는 CREATE, PUT은 업데이트, DELETE는 DELETE). 이는 사용자 호출의 결과로 수행하려는 일련의 작업이있는 이전 개념의 RPC (원격 프로 시저 호출) 개념과 다릅니다. 예를 들어 게시물과 같은 페이스 북을 설명하는 방법에 대해 생각하고 RPC를 사용하면 AddLikeToPost 및 RemoveLikeFromPost라는 서비스를 생성하고 FB 게시물과 관련된 다른 모든 서비스와 함께 관리 할 수 ​​있으므로 특별한 것을 만들 필요가 없습니다. 좋아요에 대한 개체. REST를 사용하면 삭제 및 작성 기능으로 별도로 관리되는 Like 오브젝트가 있습니다. 또한 DB에서 별도의 엔티티를 설명한다는 의미입니다. 작은 차이처럼 보일 수 있지만 그렇게하면 일반적으로 훨씬 간단한 코드와 훨씬 간단한 응용 프로그램이 만들어집니다. 이 디자인을 사용하면 일반적으로 많은 로직을 명시 적으로 추가 해야하는 RPC와 달리 대부분의 앱 로직은 객체의 구조 (모델)에서 분명합니다.

RESTful 애플리케이션을 설계하는 것은 복잡한 방식을 간단한 방식으로 설명해야하기 때문에 일반적으로 훨씬 어렵습니다. CRUD 함수 만 사용하여 모든 기능을 설명하는 것은 까다 롭지 만 그렇게 한 후에는 인생이 훨씬 간단 해지며 훨씬 짧은 방법을 작성할 것입니다.

클라이언트와 통신 할 때 세션 스테이트먼트를 사용하지 않는 것 (상태 비 저장)은 클라이언트가 누구인지, 원하는 것이 웹 메시지와 함께 전달되는지 이해하는 데 필요한 모든 정보를 의미합니다. 함수에 대한 각 호출은 자체 설명 적이며 메시지에서 참조 할 수있는 클라이언트와의 이전 대화는 없습니다. 따라서 이전 페이지와 원하는 페이지를 저장할 세션이 없기 때문에 클라이언트가 "다음 페이지를 줘"라고 말할 수 없습니다. 클라이언트가 "내 이름은 yuval입니다. 특정 포럼에있는 특정 게시물의 2 페이지 "를 참조하십시오. 즉, 통신에서 조금 더 많은 데이터를 전송해야하지만 "다음 페이지 받기"기능에서보고 된 버그를 찾는 것과의 차이점을 "

물론 더 많은 것이 있지만 내 의견으로는 이것이 티스푼의 주요 개념입니다.

HTTP는 응용 프로그램 프로토콜입니다. REST는 일련의 규칙으로, 따라야하는 특정 제한 조건이있는 분산 애플리케이션을 빌드 할 수 있습니다.

RESTful 애플리케이션을 HTTP 애플리케이션과 구별하는 REST의 가장 중요한 제약 조건을 찾고 있다면 "자체 설명"제약 조건과 하이퍼 미디어 제약 조건 (HATEOAS (Hypermedia as a Engine of Application State))이라고합니다. 가장 중요한.

자체 설명 제한 조건은 RESTful 요청이 사용자 의도에서 완전히 자체 설명 적이어야합니다. 이를 통해 중개자 (프록시 및 캐시)가 메시지에 안전하게 작동 할 수 있습니다.

HATEOAS 제약 조건은 응용 프로그램을 클라이언트의 현재 상태가 해당 웹에서의 위치를 ​​기반으로하는 링크 웹으로 전환하는 것입니다. 그것은 까다로운 개념이며 지금보다 설명하는 데 더 많은 시간이 필요합니다.

내가 이해하는 것처럼 REST는 사용 가능한 HTTP 명령을 사용하도록 강제합니다.

예를 들어, 나는 할 수 있습니다 :

GET
http://example.com?method=delete&item=xxx

그러나 나머지는 "DELETE"요청 메소드를 사용하여 "method"쿼리 매개 변수의 필요성을 제거했습니다.

DELETE
http://example.com?item=xxx

좀 빠지는...

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

REST는 처음에 HTTP 컨텍스트에서 설명되었지만 해당 프로토콜로 제한되지 않습니다. RESTful 아키텍처는 의미있는 표현 상태의 전송을 기반으로 애플리케이션에 풍부하고 균일 한 어휘를 이미 제공하는 경우 다른 애플리케이션 계층 프로토콜을 기반으로 할 수 있습니다. RESTful 애플리케이션은 선택한 네트워크 프로토콜에서 제공하는 기존의 잘 정의 된 인터페이스 및 기타 내장 기능의 사용을 최대화하고 새로운 애플리케이션 별 기능의 추가를 최소화합니다.

http://www.looselycoupled.com/glossary/SOAP

(Simple Object Access Protocol) 웹 서비스 메시지의 표준입니다. XML을 기반으로 SOAP는 봉투 형식과 내용을 설명하기위한 다양한 규칙을 정의합니다. (WSDL 및 UDDI와 함께) 웹 서비스의 세 가지 기본 표준 중 하나 인 웹 서비스 교환에 선호되는 프로토콜이지만 결코 유일한 것은 아닙니다. REST의 지지자들은 불필요한 복잡성을 추가한다고 말합니다.

REST는 웹과 같은 큰 시스템 설계에 접근하는 특정 방법입니다.

'규칙'(또는 '제약') 세트입니다.

HTTP는 이러한 규칙을 준수하는 프로토콜입니다.

REST = 대표 상태 이전

REST 는 일련의 규칙으로, 따라야 할 특정 제한 조건이있는 분산 애플리케이션을 빌드 할 수 있습니다.

REST 는 HTTP를 사용하여 해당 메시지를 전송할 수있는 XML (JSON) 메시지를 교환하는 프로토콜입니다.

풍모:

상태 비 저장이므로 클라이언트와 서버간에 연결을 유지하지 않는 것이 이상적입니다. 컨텍스트를 서버로 전달하는 것은 클라이언트의 책임이며 서버는이 컨텍스트를 저장하여 클라이언트의 추가 요청을 처리 할 수 ​​있습니다. 예를 들어, 서버가 유지 관리하는 세션은 클라이언트가 전달한 세션 식별자로 식별됩니다.

상태 비 저장의 장점 :

1. 웹 서비스는 각 메소드 호출을 개별적으로 처리 할 수 ​​있습니다.
2. 웹 서비스는 클라이언트의 이전 상호 작용을 유지할 필요가 없습니다.
3. 결과적으로 응용 프로그램 설계가 간소화됩니다.
4. HTTP 자체는 TCP와 달리 상태 비 저장 프로토콜이므로 RESTful 웹 서비스는 HTTP 프로토콜과 원활하게 작동합니다.

무국적자의 단점 :

1. 클라이언트 상태를 유지하려면 모든 요청에 ​​제목 형식의 추가 계층을 추가해야합니다.
2. 보안을 위해 모든 요청에 ​​헤더 정보를 추가해야합니다.

REST가 지원하는 HTTP 메소드 :

GET : / string / someotherstring dem 등원이며 호출 할 때마다 동일한 결과를 이상적으로 반환해야합니다.

PUT : GET과 동일합니다. dem 등원이며 자원을 업데이트하는 데 사용됩니다.

POST : URL 및 본문을 포함해야합니다. 자원을 작성하는 데 사용됩니다. 여러 번의 호출은 이상적으로 다른 결과를 반환하고 여러 개의 제품을 만들어야합니다.

삭제 : 서버에서 리소스를 삭제하는 데 사용됩니다.

머리:

HEAD 메소드는 서버가 응답에서 메시지 본문을 리턴해서는 안된다는 점을 제외하고는 GET과 동일합니다. HEAD 요청에 대한 응답으로 HTTP 헤더에 포함 된 메타 정보는 GET 요청에 대한 응답으로 전송 된 정보와 동일해야합니다.

옵션 :

이 방법을 사용하면 클라이언트는 리소스 작업을 암시하거나 리소스 검색을 시작하지 않고도 리소스 또는 서버의 기능과 관련된 옵션 및 / 또는 요구 사항을 결정할 수 있습니다.

HTTP 응답

모든 답변을 보려면 여기로 이동하십시오 .

200-OK 3XX-클라이언트 및 URL 리디렉션에서 필요한 추가 정보 400-잘못된 요청
401-403에 액세스 할 수있는 권한이 없음
-금지됨
요청이 유효하지만 서버가 조치를 거부하고 있습니다. 사용자에게 리소스에 필요한 권한이 없거나 일종의 계정이 필요할 수 있습니다.

404-
찾을 수 없음 요청한 리소스를 찾을 수 없지만 나중에 사용할 수 있습니다. 클라이언트의 후속 요청은 허용됩니다.

405-Method Not Allowed 요청 된 리소스에 대해 요청 방법이 지원되지 않습니다. 예를 들어 POST를 통해 데이터를 표시해야하는 양식에 대한 GET 요청 또는 읽기 전용 자원에 대한 PUT 요청.

404-요청을 찾을 수 없음
500-내부 서버 오류
502-잘못된 게이트웨이 오류

HTTP는 네트워크를 통해 메시지를 전송하는 통신 프로토콜입니다. SOAP는 HTTP를 사용하여 해당 메시지를 전송할 수있는 XML 기반 메시지를 교환하는 프로토콜입니다. Rest는 HTTP를 사용하여 해당 메시지를 전송할 수있는 (XML 또는 JSON) 메시지를 교환하는 프로토콜입니다.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style HTTP, FTP 또는 기타 통신 프로토콜을 사용할 수 있지만 HTTP와 함께 널리 사용됩니다.

REST implies a series of constraints about how Server and Client should interact. REST가 정의 HTTP is a communication protocol with a given mechanism for server-client data transfer되기 REST was inspired by WWW (world wide web) which largely used HTTP전에 REST API에서 가장 일반적으로 사용 되므로 HTTP로 REST API 스타일을 구현하는 것이 더 쉽습니다.

There are three major constraints in REST (but there are more):

1. 서버와 클라이언트 간의 상호 작용은 하이퍼 텍스트를 통해서만 설명해야합니다.

2.서버와 클라이언트는 느슨하게 연결되어 있고 서로에 대해 가정하지 않아야합니다. 클라이언트는 리소스 진입 점 만 알고 있어야합니다. 응답시 서버가 상호 작용 데이터를 제공해야합니다.

3.서버는 요청 컨텍스트에 대한 정보를 저장해서는 안됩니다. 요청은 독립적이며 dem 등원이어야합니다 (동일한 요청이 무한 반복되는 경우 정확히 동일한 결과가 검색됨을 의미)

그리고 HTTP는이를 달성하는 데 도움이되는 통신 프로토콜 (도구) 일뿐입니다.

자세한 정보는 다음 링크를 확인하십시오.

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

REST 는 반드시 HTTP에 연결되어 있지는 않습니다 . RESTful 웹 서비스는 RESTful 아키텍처를 따르는 웹 서비스입니다.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

에서 당신은 HTTP와 REST의 차이를 모른다

따라서 REST 아키텍처와 HTTP 1.1 프로토콜은 서로 독립적이지만 HTTP 1.1 프로토콜은 REST의 원칙과 제약을 따르는 이상적인 프로토콜로 만들어졌습니다. HTTP와 REST의 관계를 보는 한 가지 방법은 REST가 디자인이고 HTTP 1.1이 해당 디자인의 구현이라는 것입니다.

REST API는 하이퍼 텍스트 중심이어야합니다.

에서 로이 필딩의 블로그 여기 당신이 HTTP의 API 또는 REST API를 구축하고 있는지 확인하는 방법의 집합입니다 :

API 디자이너, REST API 생성을 호출하기 전에 다음 규칙을 참고하십시오.

• REST API는 단일 통신 프로토콜에 의존해서는 안되지만, 주어진 프로토콜에 대한 성공적인 매핑은 메타 데이터의 가용성, 방법 선택 등에 의존 할 수 있습니다. 일반적으로 식별을 위해 URI를 사용하는 프로토콜 요소는 식별을 위해 사용되는 URI 스킴 [여기에서 실패는 식별이 상호 작용과 분리되지 않음을 의미합니다.]
• REST API에는 HTTP의 PATCH 메소드 또는 링크 헤더 필드와 같이 지정되지 않은 표준 프로토콜 비트의 세부 사항을 채우거나 수정하는 것 외에 통신 프로토콜에 대한 변경 사항이 포함되어서는 안됩니다. 고장난 구현에 대한 해결 방법 (예 : HTML이 HTTP의 메소드 세트를 정의한다고 믿을 정도로 멍청한 브라우저와 같은)은 해결 방법이 결국 폐기 될 것으로 예상하여 별도로 또는 적어도 부록으로 정의해야합니다. [여기서 실패는 리소스 인터페이스가 일반적인 것이 아니라 개체 별이라는 것을 의미합니다.]
• REST API는 리소스를 표현하고 애플리케이션 상태를 구동하는 데 사용되는 미디어 유형을 정의하거나 기존 표준 미디어 유형에 대한 확장 관계 이름 및 / 또는 하이퍼 텍스트 가능 마크 업을 정의하는 데 거의 모든 설명 노력을 기울여야합니다. 관심있는 URI에 사용할 메소드를 설명하는 데는 모든 매체 유형 (대부분의 경우 기존 매체 유형에 의해 이미 정의 된)의 처리 규칙 범위 내에서 완전히 정의되어야합니다. [여기서의 실패는 대역 외 정보가 하이퍼 텍스트 대신 상호 작용을 주도하고 있음을 의미합니다.]
• REST API는 고정 자원 이름 또는 계층 구조 (클라이언트와 서버의 명백한 결합)를 정의해서는 안됩니다. 서버는 자신의 네임 스페이스를 자유롭게 제어 할 수 있어야합니다. 대신, 서버는 클라이언트에게 HTML 형식 및 URI 템플릿에서 수행되는 것과 같은 적절한 URI를 구성하는 방법을 미디어 유형 및 링크 관계 내에서 해당 명령을 정의하여 클라이언트에게 지시 할 수 있습니다. [여기서 실패는 클라이언트가 RPC의 기능적 커플 링과 동등한 데이터 지향적 인 도메인 별 표준과 같은 대역 외 정보로 인해 자원 구조를 가정하고 있음을 의미합니다.
• REST API에는 클라이언트에게 중요한 "유형화 된"리소스가 없어야합니다. 사양 작성자는 인터페이스 뒤의 서버 구현을 설명하기 위해 리소스 유형을 사용할 수 있지만 이러한 유형은 클라이언트와 관련이없고 보이지 않아야합니다. 클라이언트에게 중요한 유일한 유형은 현재 표현의 매체 유형과 표준화 된 관계 이름입니다. [같게]
• REST API는 의도 된 대상에 적합한 초기 URI (책갈피) 및 표준화 된 미디어 유형 세트를 넘어 사전 지식없이 입력해야합니다 (즉, API를 사용할 수있는 모든 클라이언트가 이해할 수 있음). 그 시점부터 모든 응용 프로그램 상태 전환은 수신 된 표현에 있거나 사용자가 해당 표현을 조작하여 암시하는 서버 제공 선택 사항에 대한 클라이언트 선택에 의해 구동되어야합니다. 전이는 미디어 유형 및 리소스 통신 메커니즘에 대한 클라이언트의 지식에 의해 결정 (또는 제한 될 수 있음) 될 수 있으며, 이들 모두는 즉석에서 개선 될 수있다 (예를 들어, 주문형 코드). [여기서의 실패는 대역 외 정보가 하이퍼 텍스트 대신 상호 작용을 주도하고 있음을 의미합니다.]