WSDL 대 REST 장단점

WSDL 대 REST 장단점

---

관련 :

웹 서비스 대신 REST를 사용하는 이유는 무엇입니까?

SOAP 또는 REST (즉, RESTful 방식의 HTTP / XML을 의미 함)를 사용하여 웹 서비스를 구현할지 여부를 결정할 때 알아야 할 사항과 고려해야 할 사항은 무엇입니까? 나는 이것이 모든 것에 맞는 하나의 크기가 아니라고 생각하므로 사용할 것을 어떻게 선택합니까?

---

두 프로토콜은 실제 세계에서 매우 다른 용도로 사용됩니다.

SOAP (WSDL 사용)는 문서 전달을 중심으로하는 무거운 XML 표준입니다. 이것의 장점은 요청과 응답이 매우 잘 구조화 될 수 있고 DTD를 사용할 수도 있다는 것입니다. 단점은 XML이고 매우 장황하다는 것입니다. 그러나 두 당사자가 엄격한 계약 (예 : 은행 간 통신)을해야하는 경우에 좋습니다. SOAP를 사용하면 문서에서 WS-Security와 같은 항목을 계층화 할 수 있습니다. SOAP는 일반적으로 전송에 구애받지 않으므로 반드시 HTTP를 사용할 필요는 없습니다.

REST는 매우 가볍고 HTTP 표준에 의존하여 작동합니다. 유용한 웹 서비스를 빠르게 시작하고 실행하는 것이 좋습니다. 엄격한 API 정의가 필요하지 않은 경우 이것이 갈 길입니다. 대부분의 웹 서비스가이 범주에 속합니다. API 업데이트로 인해 이전 버전을 사용하는 사람들이 버전을 지정하는 한 중단되지 않도록 API 버전을 지정할 수 있습니다. REST는 기본적으로 HTTP를 필요로하며 형식에 구애받지 않습니다 (즉, XML, JSON, HTML 등을 사용할 수 있음).

일반적으로 나는 멋진 WS- * 기능이 필요하지 않기 때문에 REST를 사용합니다. 컴퓨터가 WSDL을 사용하여 웹 서비스를 이해하도록하려면 SOAP가 좋습니다. REST 사양은 일반적으로 사람이 읽을 수만 있습니다.

---

다음 링크는 장점과 단점을 포함하여 WSDL과 REST에 대한 유용한 정보를 제공합니다.

몇 가지 핵심 사항은

1) SOAP는 REST가 점대 점 환경을 위해 설계된 분산 컴퓨팅 환경을 위해 설계되었습니다.

2) WADL을 사용하여 REST 서비스에 대한 인터페이스를 정의 할 수 있습니다.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl

---

WSDL ( "SOAP"을 의미)을 "무거운 무게"로 간주합니다. 헤비는 어떻게 중요합니까? 도구 세트가 모든 "무거운 작업"을 수행하는 경우 왜 중요합니까?

아직 복잡한 REST API를 사용할 필요가 없습니다. 그렇게 할 때 내 도구가 프록시 클래스 집합으로 기꺼이 변환되는 WSDL을 원할 것으로 예상되므로 메서드로 보이는 것을 호출 할 수 있습니다. 대신, 사소하지 않은 REST 기반 API를 사용하려면 상당한 양의 "경량"코드를 직접 작성해야한다고 생각합니다.

모든 작업이 완료 되더라도 사람이 읽을 수있는 문서를 코드로 변환하고 사람이 잘못 읽을 위험이 있습니다. WSDL은 기계가 읽을 수있는 서비스 설명이므로 "잘못 읽는"것이 훨씬 더 어렵습니다.

---

그냥 참고 :이 게시물 이후로, 나는 한 적당히 복잡 REST 서비스와 함께 일할 수있는 기회가 있었다. 나는 실제로 WSDL이나 이에 상응하는 것을 원했고 실제로 많은 코드를 직접 작성해야했다. 실제로 개발 시간의 상당 부분을 "수작업으로"서로 다른 서비스 작업을 호출하는 모든 코드의 코드 중복을 제거하는 데 소비되었습니다.

---

이것은 아마도 위의 여러 게시물에 대한 주석으로 속할 수 있지만 아직 그렇게 할 담당자가 없으므로 여기에 있습니다.

SOAP와 REST에 대해 자주 인용되는 많은 장단점이 두 기술의 실제 값이나 한계와 거의 관련이 없다는 것이 흥미 롭다고 생각합니다. 아마도 REST에 대해 가장 많이 인용되는 장점은 "가벼움"이거나 "인간이 읽을 수있는"경향이 있다는 것입니다. 한 수준에서 이것은 확실히 사실입니다. REST는 진입 장벽이 낮습니다. SOAP보다 필요한 구조가 적습니다 (하지만 여기에서는 좋은 도구가 대부분의 해답이라고 말한 사람들과 동의하지만 SOAP 도구의 대부분은 꽤 무서운).

그러나 초기 진입 비용 외에도 REST 인상은 요청 URL의 형식과 대부분의 REST 서비스에서 교환하는 데이터의 복잡성의 조합에서 비롯된 것이라고 생각합니다. REST는 더 간단하고 사람이 읽을 수있는 요청 URL을 장려하는 경향이 있으며 데이터도 더 소화하기 쉬운 경향이 있습니다. 그러나 이들은 REST에 내재되어있는 정도와 단지 우발적 일 정도입니다. 더 간단한 URL 구조는 아키텍처의 직접적인 결과이지만 SOAP 기반 서비스에도 똑같이 잘 적용될 수 있습니다. 더 소화하기 쉬운 데이터는 정의 된 구조가 없기 때문일 가능성이 높습니다. 즉, 데이터 형식을 단순하게 유지하거나 많은 작업을 수행 할 것입니다. 그래서 여기 SOAP의 추가 구조,

따라서 컴퓨터 시스템 간의 구조화 된 데이터 교환에 사용하기 위해 REST가 본질적으로 SOAP (또는 그 반대)보다 낫다는 것은 확실하지 않습니다. 위의 REST 대 SOAP와 동적 대 정적 형식의 비교가 좋은 것이라고 생각합니다. 동적 언어가 문제를 일으키는 경향이있는 곳은 시스템의 장기 유지 관리 및 유지에 있습니다 (그리고 장기적으로는 1 년 또는 2 년이 아니라 5 ~ 10 년을 말하는 것입니다). REST가 시간이 지남에 따라 동일한 문제에 직면하는지 확인하는 것은 흥미로울 것입니다. 분산 된 정보 처리 시스템을 구축한다면 통신 메커니즘으로 SOAP를 선호 할 것이라고 생각하는 경향이 있습니다 (위에서 언급 한대로 전송 및 응용 프로그램 프로토콜 계층화와 유연성 때문에).

다른 곳에서는 REST가 더 적절 해 보입니다. 페이로드에 관계없이 클라이언트와 서버 간의 AJAX가 한 가지 주요 예입니다. 나는 이러한 유형의 연결의 수명에 대해별로 신경 쓰지 않으며 사용의 용이성과 유연성이 최고입니다. 유사하게 외부 서비스에 대한 빠른 액세스가 필요하고 시간이 지남에 따라 상호 작용의 유지 관리 가능성에 대해 신경 쓰지 않을 것이라고 생각했다면 (다시 말하지만 REST가 더 많은 비용을 지불하게 될 것이라고 가정하고 있습니다. 또는 다른), REST를 선택하여 신속하게 출입 할 수 있습니다.

어쨌든 둘 다 실행 가능한 기술이며 주어진 응용 프로그램에 대해 어떤 장단점을 만들고 싶은지에 따라 잘 (또는 좋지 않은) 서비스를 제공 할 수 있습니다.

---

REST는 프로토콜이 아닙니다. 건축 스타일입니다. 또는 원하는 경우 패러다임. 즉, SOAP가 정의 된 것이 훨씬 느슨하다는 것을 의미합니다. 기본 CRUD의 경우 Atompub와 같은 표준 프로토콜에 의존 할 수 있지만 대부분의 서비스에는 그 이상의 명령이 있습니다.

소비자로서 SOAP는 언어 지원에 따라 축복 또는 저주가 될 수 있습니다. SOAP는 엄격하게 유형이 지정된 시스템에서 모델링되므로 정적으로 유형이 지정된 언어에서 가장 잘 작동합니다. 동적 인 언어의 경우 쉽게 엉망이되고 불필요해질 수 있습니다. 또한 클라이언트 라이브러리 지원은 Java 및 .NET의 세계 밖에서는 좋지 않습니다.

---

나에게 우리는 웹 서비스라는 단어를 사용할 때주의해야합니다. 우리는 SOAP 웹 서비스, REST 웹 서비스 또는 다른 종류의 웹 서비스에 대해 이야기하고 있는지 항상 지정해야합니다. 왜냐하면 우리는 여기에서 다른 것에 대해 이야기하고 있고 모든 웹 서비스의 이름을 지정하면 사람들이 더 이상 이해하지 못하기 때문입니다.

기본적으로 SOAP 웹 서비스는 수년 동안 매우 잘 확립되어 있으며 SOAP 사양을 기반으로 통신하는 방법을 설명하는 엄격한 사양을 따릅니다. 이제 REST 웹 서비스는 조금 더 새롭고 통신 프로토콜을 사용하지 않기 때문에 기본적으로 더 간단 해 보입니다. 기본적으로 REST 웹 서비스를 사용할 때 보내고받는 것은 일반 XML입니다. 사람들은 SOAP와 같은보다 정교한 통신 프로토콜을 처리 할 필요없이 원하는 방식으로 xml을 구문 분석 할 수 있기 때문에이를 좋아합니다.

To me REST services are almost like if you would create a servlet instead of a SOAP web service. The servlet get data in and return data out. The format of the data are xml based. We can also imagine to use something else than xml if we want. For instance tags could be used instead of xml and that would be not REST anymore but something else (Could be even lighter in term of weight because xml is not light by nature). Would we call that still a web service? Yes we could but that will not follow any current standard and this is the main issue here if we start to call everything web services but we can do it the way we want then we are loosing on the interoperability side of the things. That means that the format of the data that is exchanged with the web service is not standardized anymore. That requires then that server and client agree on the format of the data whereas with SOAP this is all predefined already and server and client can interoperate without to know each other because they follow the same standard.

What people don't like with SOAP is that they have hard time to understand it and they cannot generate the queries manually. Computers can do that very well however so this is where we need to be clear: are web services queries and response supposed to be used directly by the end users or do we agree that web services are underneath API called by computer systems based on some normalized standards?

---

SOAP: It can be transported via SMTP also, means we can invoke the service using Email simple text format also

It needs additional framework/engine should be in web service consumer machine to convert SOAP message to respective objects structure in various languages.

REST: Now WSDL2.0 supports to describe REST web service also

We can use when you want to make your service as lightweight, example calling from mobile devices like cell phone, pda etc...

---

for enterprise systems in which your system is confined within your corporations, its easier and proper to use soap because you are almost in control of clients. it's easier since there a variety of tools which creates classes (proxies) and looks like you are doing your regular OOP which matches your java or .net environment (in which most corporates use).

I would use REST for internet facing applications for exposing interfaces (like twitter api) since clients can be using javascripts or html or others in which typing is not strict. REST being more liberal makes more sense.

Also for internet facing clients (world wide web), its easier to parse json or xml coming out of a rest interface rather than a purely xml coming from a soap interface. it's hard to use proxies on javascript and javascript does not naturally support objects. If you are using REST with javascript, you would just usually parse the json string and you're off. internet facing interfaces are usually very simple (so most of the time its simple parsing) and does not usually demand consistency that is why REST is adequate enough.

For enterprise applications I don't think REST is adequate because transactions, security, strict typing, schemas play a very important in enterprise applications development that is why SOAP is more suited for them.

My conclusion is that SOAP is for Enterprise systems, REST is for the Internet or WWW. You can use it interchangeably but you may find yourself having a difficult time eventually not using the correct tool for the job.

sorry for my bad english.

---

In defence of REST it closely follows the principles of HTTP and addressability e.g. read operations use GET, update operations use POST etc. I find this to be a far cleaner approach. The Oreilly book RESTful Web Services explains this far better than I can, if you read it I think you would prefer the REST approach

---

The toolset on the client side would be one. And the familiarity with SOAP services the other. More and more services are going the RESTful route these days, and testing such services can be done with simple cURL examples. Although, it's not all that difficult to implement both methods and allow for the widest utilization from clients.

If you need to pick one, I'd suggest REST, it's easier.

---

The previous answers contain a lot of information, but I think there is a philosophical difference that hasn't been pointed out. SOAP was the answer to "how to we create a modern, object-oriented, platform and protocol independent successor to RPC?". REST developed from the question, "how to we take the insights that made HTTP so successful for the web, and use them for distributed computing?"

SOAP is a about giving you tools to make distributed programming look like ... programming. REST tries to impose a style to simplify distributed interfaces, so that distributed resources can refer to each other like distributed html pages can refer to each other. One way it does that is attempt to (mostly) restrict operations to "CRUD" on resources (create, read, update, delete).

REST is still young -- although it is oriented towards "human readable" services, it doesn't rule out introspection services, etc. or automatic creation of proxies. However, these have not been standardized (as I write). SOAP gives you these things, but (IMHO) gives you "only" these things, whereas the style imposed by REST is already encouraging the spread of web services because of its simplicity. I would myself encourage newbie service providers to choose REST unless there are specific SOAP-provided features they need to use.

In my opinion, then, if you are implementing a "greenfield" API, and don't know that much about possible clients, I would choose REST as the style it encourages tends to help make interfaces comprehensible, and easy to develop to. If you know a lot about client and server, and there are specific SOAP tools that will make life easy for both, then I wouldn't be religious about REST, though.

---

You can easily transition your WSDL-spewing WCF web components to other uses just by changing your configuration settings. You can go across HTTP and then also named pipes, tcp, custom protocols, etc without having to change your code. I believe WCF components may also be easier to set up for stuff like security, two-way calling, transactions, concurrency, etc.

REST pretty much limits you to HTTP (which is fine in many cases).

---

I know that this discussion is an old one, but after reading all the answers and commented, I believe that everyone missed the most important point about the difference between the 2 systems: SOAP uses complex types to not only give you the data, but validate it and keep it in the strict type designation it was defined for. A WSDL tells you what the data format is, what the data type is, allows you to add reg-ex pattern-style rules, and defines how many times a piece of data must be, and may be, allowed in a request/response. Rest on the other-hand has none of these mechanisms.

SOAP is complex and heavy because it allows you to send complex heavy hierarchical data. REST is plain text, with the origin and endpoint sorting out the rules.

SOAP is business independent, because it has all the data rules embedded in the document.

The difference between SOAP and REST is that SOAP is a self-contained business oriented schema. REST is a text document.

참고URL : https://stackoverflow.com/questions/840653/wsdl-vs-rest-pros-and-cons