REST (Representational State Transfer) 및 SOAP (Simple Object Access Protocol)

REST (Representational State Transfer) 및 SOAP (Simple Object Access Protocol)

---

누군가 REST 가 무엇이며 일반 영어 로 SOAP 가 무엇인지 설명 할 수 있습니까 ? 그리고 웹 서비스는 어떻게 작동합니까?

---

SOAP 및 REST에 대한 간단한 설명

SOAP- "단순 객체 액세스 프로토콜"

SOAP는 인터넷을 통해 메시지 또는 소량의 정보를 전송하는 방법입니다. SOAP 메시지는 XML 형식이며 일반적으로 HTTP (하이퍼 텍스트 전송 프로토콜)를 사용하여 전송됩니다.

---

휴식-대표적 상태 이전

Rest는 클라이언트와 서버간에 데이터를주고받는 간단한 방법이며 정의 된 표준이 많지 않습니다. JSON, XML 또는 일반 텍스트로 데이터를 보내고받을 수 있습니다. SOAP에 비해 가볍습니다.

---

---

두 방법 모두 많은 대형 플레이어가 사용합니다. 그것은 선호도의 문제입니다. 사용하고 이해하는 것이 더 간단하기 때문에 내 선호는 REST입니다.

SOAP (Simple Object Access Protocol) :

• SOAP는 HTTP 또는 때때로 TCP / IP 위에 XML 프로토콜을 구축합니다.
• SOAP는 기능 및 데이터 유형을 설명합니다.
• SOAP는 XML-RPC의 후속 제품이며 매우 유사하지만 표준 통신 방법을 설명합니다.
• 여러 프로그래밍 언어에는 SOAP에 대한 기본 지원이 있으며 일반적으로 웹 서비스 URL을 제공하고 특정 코드없이 웹 서비스 함수를 호출 할 수 있습니다.
• 전송되는 이진 데이터는 먼저 base64 인코딩과 같은 형식으로 인코딩되어야합니다.
• 이와 관련된 여러 프로토콜 및 기술 : WSDL, XSD, SOAP, WS-Addressing

REST (Representational State Transfer) :

• REST는 HTTP를 통할 필요는 없지만 아래의 대부분의 요점에는 HTTP 편향이 있습니다.
• REST는 매우 가볍습니다. 잠시만 기다려주세요. SOAP가 생성 한 이러한 복잡성이 모두 필요하지는 않습니다.
• 일반적으로 모든 것을 설명하는 큰 XML 형식 대신 일반 HTTP 메서드를 사용합니다. 예를 들어 리소스를 얻으려면 HTTP GET을 사용하고 리소스를 서버에 배치하려면 HTTP PUT를 사용합니다. 서버에서 리소스를 삭제하려면 HTTP DELETE를 사용합니다.
• REST는 HTTP GET, POST 및 PUT 메서드를 사용하여 서버의 리소스를 업데이트한다는 점에서 매우 간단합니다.
• REST는 일반적으로 ROA ( Resource Oriented Architecture) 와 함께 사용하는 것이 가장 좋습니다 . 이 사고 방식에서는 모든 것이 하나의 자원이며 이러한 자원을 사용하여 작업 할 수 있습니다.
• 프로그래밍 언어에 HTTP 라이브러리가 있고 대부분의 경우 REST HTTP 프로토콜을 매우 쉽게 사용할 수 있습니다.
• 바이너리 데이터 또는 바이너리 리소스는 요청에 따라 간단히 전달할 수 있습니다.

Google에서 REST와 SOAP에 대한 끝없는 논쟁 이 있습니다 .

내가 가장 좋아하는 것은 이것 입니다. 2013 년 11 월 27 일 업데이트 : Paul Prescod의 사이트가 오프라인으로 전환 된 것으로 보이며이 기사는 더 이상 사용할 수 없습니다. 사본은 Wayback Machine 또는 CiteSeerX 에서 PDF로 찾을 수 있습니다 .

---

쉬다

REST의 주요 아이디어가 매우 간단하다는 것을 이해합니다. 우리는 수년 동안 웹 브라우저를 사용해 왔으며 웹 사이트가 얼마나 쉽고 유연하며 성능이 뛰어난 지 보았습니다. HTML 사이트는 사용자 상호 작용의 기본 수단으로 하이퍼 링크와 양식을 사용합니다. 그들의 주요 목표는 고객 이 현재 상태에서 사용할 수 있는 링크 만 알 수 있도록 하는 것 입니다. REST는 단순히 '애플리케이션을 통해 인간 클라이언트보다 컴퓨터를 구동하는 데 동일한 원칙을 사용하지 않는 이유는 무엇입니까?'라고 말합니다. 이것을 WWW 인프라의 힘과 결합하면 훌륭한 분산 애플리케이션을 구축 할 수있는 킬러 도구를 얻을 수 있습니다.

또 다른 가능한 설명은 수학적으로 생각하는 사람들에 대한 것입니다. 각 응용 프로그램은 기본적으로 비즈니스 논리 작업이 상태 전환 인 상태 시스템입니다. REST의 개념은 각 전환을 리소스에 대한 일부 요청에 매핑하고 클라이언트에게 현재 상태에서 사용 가능한 전환을 나타내는 링크를 제공하는 것입니다. 따라서 표현과 링크를 통해 상태 머신을 모델링합니다. 이것이 REpresentational State Transfer라고 불리는 이유입니다.

모든 답변이 메시지 형식이나 HTTP 동사 사용에 초점을 맞춘 것처럼 보이는 것은 놀랍습니다. 사실 메시지 형식은 전혀 중요하지 않으며 REST는 서비스 개발자가 문서화 한 경우 어떤 형식이든 사용할 수 있습니다. HTTP 동사는 서비스를 CRUD 서비스로만 만들지 만 아직 RESTful은 아닙니다. 실제로 서비스를 REST 서비스로 바꾸는 것은 데이터와 함께 서버 응답에 포함 된 하이퍼 링크 (하이퍼 미디어 컨트롤이라고도 함)이며, 그 양은 클라이언트가 해당 링크에서 다음 작업을 선택하기에 충분해야합니다.

불행히도 Roy Fielding의 논문을 제외하고 웹에서 REST에 대한 정확한 정보를 찾는 것은 다소 어렵습니다 . (그는 REST를 파생 한 사람입니다). SOAP에서 REST로 발전하는 방법에 대한 포괄적 인 단계별 자습서를 제공하는 'REST in Practice'책 을 추천합니다 .

비누

이것은 RPC (원격 프로 시저 호출) 아키텍처 스타일의 가능한 형태 중 하나입니다. 본질적으로 클라이언트가 마치 로컬 메서드를 호출하는 것처럼 서비스 경계 (네트워크, 프로세스 등)를 통해 서버의 메서드를 호출 할 수있는 기술 일뿐입니다. 물론 속도, 신뢰성 등에서 로컬 메서드를 호출하는 것과 실제로는 다르지만 아이디어는 간단합니다.

비교

전송 프로토콜, 메시지 형식, xsd, wsdl 등과 같은 세부 정보는 RPC와 REST를 비교할 때 중요하지 않습니다. 가장 큰 차이점은 RPC 서비스는 RPC API에서 자신 만 아는 의미론으로 자체 애플리케이션 프로토콜을 설계하여 자전거를 재창조한다는 것입니다. 따라서 모든 클라이언트는 서비스를 사용하기 전에이 프로토콜을 이해해야하며 모든 요청의 독점적 의미 체계로 인해 캐시와 같은 일반 인프라를 구축 할 수 없습니다. 또한 RPC API는 현재 상태에서 허용되는 작업을 제안하지 않으므로 추가 문서에서 파생되어야합니다. 반면 REST는 균일 한 인터페이스를 사용하여 다양한 클라이언트가 API 의미론을 어느 정도 이해할 수 있도록하고 하이퍼 미디어 컨트롤 (링크)을 사용하여 각 상태에서 사용 가능한 옵션을 강조 표시합니다. 그러므로,

In a way, SOAP (as any other RPC) is an attempt to tunnel through a service boundary treating the connecting media as a black box capable of transmitting messages only. REST is a decision to acknowledge that the Web is a huge distributed information system, to accept the world as is and learn to master it instead of fighting against it.

SOAP seems to be great for internal network APIs, when you control both the server and the clients, and while the interactions are not too complex. It's more natural for developers to use it. However, for a public API that is used by many independent parties, is complex and big, REST should fit better. But this last comparison is very fuzzy.

Update

My experience has unexpectedly shown REST development to be more difficult than SOAP. At least for .NET. While there are great frameworks like ASP.NET Web API, there's no tooling that would automatically generate client-side proxy. Nothing like 'Add Web Service Reference' or 'Add WCF Service Reference'. One has to write all serialization and service querying code by hand. And man, that's lots of boilerplate code. I think REST development needs something similar to WSDL and tooling implementation for each development platform. In fact, there seems to be a good ground: WADL or WSDL 2.0, but neither of the standards seems to be well-supported.

Update (Jan 2016)

Turns out there is now a wide variety of tools for REST API definition. My personal preference is currently RAML.

How Web Services work

Well, this is a too broad question, because it depends on the architecture and technology used in the specific web service. But in general, a web service is simply some application in the Web that can accept requests from clients and return responses. It's exposed to the Web, thus it's a web service, and it's typically available 24/7, that's why it's a service. Of course, it solves some problem (otherwise why would someone ever use a web service) for its clients.

---

This is the simplest explanation you will ever find.

This article takes a husband to wife narrative, where the husband explains to his wife about REST, in pure layman terms. Must read!

how-i-explained-rest-to-my-wife (original link)
how-i-explained-rest-to-my-wife (2013-07-19 working link)

---

SOAP - Simple Object Access Protocol is a protocol!

REST - REpresentational State Transfer is an architectural style!

SOAP is an XML protocol used to transfer messages, typically over HTTP

REST and SOAP are arguably not mutually exclusive. A RESTful architecture might use HTTP or SOAP or some other communication protocol. REST is optimized for the web and thus HTTP is a perfect choice. HTTP is also the only protocol discussed in Roy Fielding's paper.

Although REST and SOAP are clearly very different, the question does illuminate the fact that REST and HTTP are often used in tandem. This is primarily due to the simplicity of HTTP and its very natural mapping to RESTful principles.

Fundamental REST Principles

Client-Server Communication

Client-server architectures have a very distinct separation of concerns. All applications built in the RESTful style must also be client-server in princple.

Stateless

Each each client request to the server requires that its state be fully represented. The server must be able to completely understand the client request without using any server context or server session state. It follows that all state must be kept on the client. We will discuss stateless representation in more detail later.

Cacheable

Cache constraints may be used, thus enabling response data to to be marked as cacheable or not-cachable. Any data marked as cacheable may be reused as the response to the same subsequent request.

Uniform Interface

All components must interact through a single uniform interface. Because all component interaction occurs via this interface, interaction with different services is very simple. The interface is the same! This also means that implementation changes can be made in isolation. Such changes, will not affect fundamental component interaction because the uniform interface is always unchanged. One disadvantage is that you are stuck with the interface. If an optimization could be provided to a specific service by changing the interface, you are out of luck as REST prohibits this. On the bright side, however, REST is optimized for the web, hence incredible popularity of REST over HTTP!

The above concepts represent defining characteristics of REST and differentiate the REST architecture from other architectures like web services. It is useful to note that a REST service is a web service, but a web service is not necessarily a REST service.

See this blog post on REST Design Principals for more details on REST and the above stated bullets.

---

I like Brian R. Bondy's answer. I just wanted to add that Wikipedia provides a clear description of REST. The article distinguishes it from SOAP.

REST is an exchange of state information, done as simply as possible.

SOAP is a message protocol that uses XML.

One of the main reasons that many people have moved from SOAP to REST is that the WS-* (called WS splat) standards associated with SOAP based web services are EXTREMELY complicated. See wikipedia for a list of the specifications. Each of these specifications is very complicated.

EDIT: for some reason the links are not displaying correctly. REST = http://en.wikipedia.org/wiki/REST

WS-* = http://en.wikipedia.org/wiki/WS-*

---

Both SOAP webservices and REST webservices can use the HTTP protocol and other protocols as well (just to mention SOAP can be the underlying protocol of REST). I will talk only about the HTTP protocol related SOAP and REST, because this is the most frequent usage of them.

SOAP

SOAP ("simple" object access protocol) is a protocol (and a W3C standard). It defines how to create, send and process SOAP messages.

• SOAP messages are XML documents with a specific structure: they contain an envelope which contains the header and the body section. The body contains the actual data - we want to send - in an XML format. There are two encoding styles, but we usually choose literal, which means that our application or its SOAP driver does the XML serialization and unserialization of the data.

• SOAP messages travel as HTTP messages with SOAP+XML MIME subtype. These HTTP messages can be multipart, so optionally we can attach files to SOAP messages.

• Obviously we use a client-server architecture, so the SOAP clients send requests to the SOAP webserices and the services send back responses to the clients. Most of the webservices use a WSDL file to describe the service. The WSDL file contains the XML Schema (XSD hereafter) of the data we want to send and the WSDL binding which defines how the webservice is bound to the HTTP protocol. There are two binding styles: RPC and document. By the RPC style binding the SOAP body contains the representation of an operation call with the parameters (HTTP requests) or the return values (HTTP response). The parameters and return values are validated against the XSD. By the document style binding the SOAP body contains an XML document which is validated against the XSD. I think the document binding style is better suited to event based systems, but I never used that binding style. The RPC binding style is more prevalent, so most people use SOAP for XML/RPC purposes by distributed applications. The webservices usually find each other by asking an UDDI server. UDDI servers are registries which store the location of the webservices.

SOAP RPC

So the - in my opinion - most prevalent SOAP webservice uses RPC binding style and literal encoding style and it has the following properties:

• It maps URLs to operations.
• It sends messages with SOAP+XML MIME subtype.
• It can have a server side session store, there are no constraints about that.
• The SOAP client drivers use the WSDL file of the service to convert the RPC operations into methods. The client side application communicates with the SOAP webservice by calling these methods. So most of the SOAP clients break by interface changes (resulting method names and/or parameter changes).
• It is possible to write SOAP clients which won't break by interface changes using RDF and find operations by semantics, but semantic webservice are very rare and they don't necessarily have a non breaking client (I guess).

REST

REST (representational state transfer) is an architecture style which is described in the dissertation of Roy Fielding. It does not concern about protocols like SOAP does. It starts with a null architecture style having no constraints and defines the constraints of the REST architecture one by one. People use the term RESTful for webservices which fulfill all of the REST constraints, but according to Roy Fielding, there are no such things as REST levels. When a webservice does not meet with every single REST constraint, then it is not a REST webservice.

REST constraints

• Client - server architecture - I think this part is familiar to everyone. The REST clients communicate with the REST webservices, the webservices maintain the common data - resource state hereafter - and serve it to the clients.
• Stateless - The "state transfer" part of the abbreviation: REST. The clients maintain the client state (session/application state), so the services must not have a session storage. The clients transfer the relevant part of the client state by every request to the services which respond with the relevant part of the resource state (maintained by them). So requests don't have context, they always contain the necessary information to process them. For example by HTTP basic auth the username and the password is stored by the client, and it sends them with every request, so authentication happens by every request. This is very different from regular webapplications where authentication happens only by login. We can use any client side data storage mechanism like in-memory(javascript), cookies, localStorage, and so on... to persist some parts of the client state if we want. The reason of the statelessness constraint, that the server scales well - even by very high load (millions of users) - when it does not have to maintain the session of every single client.
• Cache - The response must contain information about it can be cached by the client or not. This improves scalability further.

• Uniform interface

  • Identification of resources - REST resource is the same as RDF resource. According to Fielding if you can name something, then it can be a resource, for example: "the current local weather" can be a resource, or "your mobile phone" can be a resource, or "a specific web document" can be a resource. To identify a resource you can use resource identifiers: URLs and URNs (for example ISBN number by books). A single identifier should belong only to a specific resource, but a single resource can have many identifiers, which we frequently exploit for example by pagination with URLs like https://example.com/api/v1/users?offset=50&count=25. URLs have some specifications, for example URLs with the same pathes but different queries are not identical, or the path part should contain the hierarhical data of the URL and the query part should contain the non-hierarchical data. These are the basics of how to create URLs by REST. Btw. the URL structure does matter only for the service developers, a real REST client does not concern with it. Another frequently asked question is API versioning, which is an easy one, because according to Fielding the only constant thing by resource is semantics. If the semantics change, then you can add a new version number. You can use classical 3 number versioning and add only the major number to the URLs (https://example.com/api/v1/). So by backward compatible changes nothing happens, by non-backward compatible changes you will have a non-backward compatible semantics with a new API root https://example.com/api/v2/. So the old clients won't break, because they can use the https://example.com/api/v1/ with the old semantics.
  • Manipulation of resources through representations - You can manipulate the data related to resources (resource state) by sending the intended representation of the resources - along with the HTTP method and the resource identifier - to the REST service. For example if you want to rename a user after marriage, you can send a PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} request where the {name: "Mrs Smith"} is a JSON representation of the intended resource state, in other words: the new name. This happens vica-versa, the service sends representations of resources to the clients in order to change their states. For example if we want to read the new name, we can send a GET https://example.com/api/v1/users/1?fields="name" retrieval request, which results in a 200 ok, {name: "Mrs Smith"} response. So we can use this representation to change the client state, for example we can display a "Welcome to our page Mrs Smith!" message. A resource can have many representations depending on the resource identifier (URL) or the accept header we sent with the request. For example we can send an image of Mrs Smith (probably not nude) if image/jpeg is requested.
  • Self-descriptive messages - Messages must contain information about how to process them. For example URI and HTTP method, content-type header, cache headers, RDF which describes the meaning of the data, etc... It is important to use standard methods. It is important to know the specification of the HTTP methods. For example GET means retrieving information identified by the request URL, DELETE means asking the server to delete the resource identified by the given URL, and so on... HTTP status codes have a specification as well, for example 200 means success, 201 means the a new resource has been created, 404 means that the requested resource was not found on the server, etc... Using existing standards is an important part of REST.

  • Hypermedia as the engine of application state (HATEOAS hereafter) - Hypermedia is a media type which can contain hyperlinks. By the web we follow links - described by a hypermedia format (usually HTML) - to achieve a goal, instead of typing the URLs into the addres bar. REST follows the same concept, the representations sent by the service can contain hyperlinks. We use these hyperlinks to send requests to the service. With the response we get data (and probably more links) which we can use to build the new client state, and so on... So that's why hypermedia is the engine of application state (client state). You probably wonder how do clients recognize and follow the hyperlinks? By humans it is pretty simple, we read the title of the link, maybe fill input fields, and after that just a single click. By machines we have to add semantics to the links with RDF (by JSON-LD with Hydra) or with hypermedia specific solutions (for example IANA link relations and vendor specific MIME types by HAL+JSON). There are many machine readable XML and JSON hypermedia formats, just a short list of them:

    • XHTML
    • ATOM+XML
    • RDF+XML
    • HAL+XML
    • HAL+JSON
    • JSON-LD
    • RDF+JSON
    • Siren
    • Collection+JSON

    Sometimes it is hard to choose...

• Layered system - We can use multiple layers between the clients and the services. None of them should know about all of these additonal layers, just of layer right next to it. These layers can improve scalability by applying caches and load balancing or they can enforce security policies.
• Code on demand - We can send back code which extends the functionality of the client, for example javascript code to a browser. This is the only optional constraint of REST.

REST webservice - SOAP RPC webservice differences

So a REST webservice is very different from a SOAP webservice (with RPC binding style and literal encoding style)

• It defines an uniform interface (intead of a protocol).
• It maps URLs to resources (and not operations).
• It sends messages with any MIME types (instead of just SOAP+XML).
• It has a stateless communication, and so it cannot have a server side session storage. (SOAP has no constraint about this)
• It serves hypermedia and the clients use links contained by that hypermedia to request the service. (SOAP RPC uses operation bindings described in the WSDL file)
• It does not break by URL changes only by semantics changes. (SOAP RPC clients without using RDF semantics break by WSDL file changes.)
• It scales better than a SOAP webservice because of its stateless behavior.

and so on...

A SOAP RPC webservice does not meet all of the REST constraints:

• client-server architecture - always
• stateless - possible
• cache - possible
• uniform interface - never
• layered system - never
• code on demand (optional) - possible

---

Well I'll begin with the second question: What are Web Services? , for obvious reasons.

WebServices are essentially pieces of logic(which you may vaguely refer to as a method) that expose certain functionality or data. The client implementing(technically speaking, consuming is the word) just needs to know what are the parameter(s) the method is going to accept and the type of data it is going to return(if at all it does).

The following Link says it all about REST & SOAP in an extremely lucid manner.

REST vs SOAP

If you also want to know when to choose what (REST or SOAP), all the more reason to go through it!

---

SOAP and REST both refer to ways for different systems to talk to each other.

REST does this using techniques that resemble the communication that your browser has with web servers: using GET to request a web page, POSTing in form fields, etc.

SOAP provides for something similar but does everything through sending blocks of XML back and forth. Another key component of SOAP is WSDL which is an XML document that describes what functions and data elements are supported. WSDLs can be used to programmatically "discover" what functions are supported as well as to generate programming code stubs.

---

I think that this is as easy as I can explain it. Please, anyone is welcome to correct me or add to this.

SOAP is a message format used by disconnected systems (like across the internet) to exchange information / data. It does with XML messages going back and forth.

Web services transmit or receive SOAP messages. They work differently depending on what language they are written in.

---

The problem with SOAP is that it is in conflict with the ideals behind the HTTP stack. Any middleware should be able to work with HTTP requests without understanding the content of the request or response, but for example a regular HTTP caching server won't work with SOAP requests without knowing only which parts of the SOAP content matter for caching. SOAP just uses HTTP as a wrapper for its own communications protocol, like a proxy.

---

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

---

SOAP – "Simple Object Access Protocol"

SOAP is a slight of transferring messages, or little amounts of information over the Internet. SOAP messages are formatted in XML and are typically sent controlling HTTP.

REST – "REpresentational State Transfer"

REST is a rudimentary proceed of eventuality and receiving information between fan and server and it doesn't have unequivocally many standards defined. You can send and accept information as JSON, XML or even plain text. It's light weighted compared to SOAP.

---

SOAP­based Web Services In short, the SOAP­based Services model views the world as an ecosystem of co­equal peers that cannot control each other, but have to work together by honoring published contracts. It's a valid model of the messy real world, and the metadata ­based contracts form the SOAP Service Interface.

we can still associate SOAP with XML­based Remote Procedure Calls, but SOAP­based Web Services technology has emerged into a flexible and powerful messaging model.

SOAP assumes all systems are independent and no system has any knowledge of the internals of another and internal functionality. The most such systems can do is send messages to one another and hope they will be acted upon. Systems publish contracts that they undertake to honor, and other systems rely upon these contracts to exchange messages with them.

Contracts between systems are collectively called metadata, and comprise service descriptions, the message exchange patterns supported and the policies governing qualities of service (a service may need to be encrypted, reliably delivered, etc.) A service description, in turn, is a detailed specification of the data (message documents) that will be sent and received by the system. The documents are described using an XML description language like XML Schema Definition. As long as all systems honor their published contracts, they can inter operate, and changes to the internals of systems never affect any other. Every system is responsible for translating its own internal implementations to and from its contracts

REST-표현 상태 전송. 물리적 프로토콜은 HTTP입니다. 기본적으로 REST는 URL로 고유하게 식별 할 수있는 웹상의 모든 고유 리소스입니다. 이러한 리소스에서 수행 할 수있는 모든 작업은 HTTP 동사에 매핑되는 제한된 동사 집합 ( "CRUD"동사)에 의해 설명 될 수 있습니다.

REST는 SOAP보다 "무거움"이 훨씬 적습니다.

웹 서비스 작동

참고 URL : https://stackoverflow.com/questions/209905/representational-state-transfer-rest-and-simple-object-access-protocol-soap