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) 메시지를 교환하는 프로토콜입니다.
풍모:
상태 비 저장이므로 클라이언트와 서버간에 연결을 유지하지 않는 것이 이상적입니다. 컨텍스트를 서버로 전달하는 것은 클라이언트의 책임이며 서버는이 컨텍스트를 저장하여 클라이언트의 추가 요청을 처리 할 수 있습니다. 예를 들어, 서버가 유지 관리하는 세션은 클라이언트가 전달한 세션 식별자로 식별됩니다.
상태 비 저장의 장점 :
- 웹 서비스는 각 메소드 호출을 개별적으로 처리 할 수 있습니다.
- 웹 서비스는 클라이언트의 이전 상호 작용을 유지할 필요가 없습니다.
- 결과적으로 응용 프로그램 설계가 간소화됩니다.
- HTTP 자체는 TCP와 달리 상태 비 저장 프로토콜이므로 RESTful 웹 서비스는 HTTP 프로토콜과 원활하게 작동합니다.
무국적자의 단점 :
- 클라이언트 상태를 유지하려면 모든 요청에 제목 형식의 추가 계층을 추가해야합니다.
- 보안을 위해 모든 요청에 헤더 정보를 추가해야합니다.
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-잘못된 게이트웨이 오류
