RESTful 웹 서비스가 필요한 이유는 무엇입니까?

RESTful 웹 서비스가 필요한 이유는 무엇입니까?

---

RESTful 웹 서비스를 배우려고합니다 (CS 석사 학위 프로그램의 일부이기 때문에이 작업을 수행해야한다고 말하는 것이 좋습니다).

Wikipedia에서 일부 정보를 읽었으며 Sun Developer Network에서 REST에 대한 기사를 읽었으며 쉬운 기술이 아니며 RESTful 앱을 빌드하기위한 특수 프레임 워크가 있으며 SOAP 웹 서비스와 비교되는 경우가 많습니다. 프로그래머는 SOAP 사용시기와 REST가 좋은 방법 일 수 있음을 이해해야합니다.

몇 년 전, SOAP는 매우 인기가 있었으며 (유행?) 아이템 'SOAP'은 모든 훌륭한 이력서에 존재해야한다는 것을 기억합니다. 그러나 실제로는 매우 드물게 사용되었으며 매우 간단한 목적을 달성하기 위해 사용되었습니다.

REST가 또 다른 '패션의 마지막 단어'인 것 같습니다 (또는 실제로 REST를 본 적이 없기 때문에 완전히 잘못 될 수 있습니다).

REST를 사용해야하는 이유와 REST 없이는 왜 똑같이 할 수 없는지 (또는 REST 없이도 같은 시간을 더 많이 소비해야하는 이유) 몇 가지 예를 들어 주시겠습니까?

UPD : 불행히도 나는 첫 번째 의견에서 내 마음을 날려 버릴 수있는 구체적인 주장을 볼 수 없습니다. REST가 멋진 기술이라고 생각하게하십시오!

다음과 같은 답변을보고 싶습니다.

또 다른 복잡한 HelloWorld 응용 프로그램을 개발 중이며 많은 양의 작은 데이터를 전송해야하며 동료에게 REST 솔루션을 제안했습니다.

– 오 젠장! Jonny,이 앱을 구현하기 위해 반드시 REST를 사용해야합니다!
– 예, Billy, REST를 사용할 수 있지만 SOAP를 사용하는 것이 좋습니다. HelloWorld 응용 프로그램 개발에 대해 알고 있기 때문에 저를 믿으십시오.
– 그러나 SOAP는 지난 세기의 구식 기술이며 더 나은 기술을 사용할 수 있습니다.
– Billy, REST 실험에 3 일을 소비 할 준비가 되셨습니까? 2 시간 안에 SOAP로이를 수행 할 수 있습니다.
– 예, SOAP를 사용 하여 동일한 보안 / 성능 // 확장 성 / 다른 것을 달성하기 위해 더 많은 시간을 소비 할 것이라고 확신합니다. HelloWorld 응용 프로그램은 지금부터 REST로만 개발해야합니다.

---

분산 응용 프로그램에서 클라이언트와 서버 구성 요소 간의 연결 을 최소화하는 것이 매우 중요한 경우 REST를 사용해야합니다 .

제어 할 수없는 많은 다른 클라이언트 가 서버를 사용하는 경우에 해당 될 수 있습니다 . 클라이언트 소프트웨어를 업데이트하지 않고 서버를 정기적으로 업데이트 하려는 경우도 있습니다 .

이 낮은 수준의 커플 링을 달성하는 것이 쉽지 않다는 것을 확신 할 수 있습니다 . 성공하려면 REST의 모든 제약 조건을 따르는 것이 중요합니다. 순수한 상태 비 저장 연결을 유지하는 것은 어렵습니다. 올바른 미디어 유형을 선택하고 데이터를 형식으로 압축하는 것은 까다로운 작업입니다. 자신 만의 미디어 유형을 만드는 것이 더 어려울 수 있습니다.

풍부한 서버 동작을 균일 한 HTTP 인터페이스에 적용하는 것은 혼란 스러울 수 있으며, 비교적 간단한 RPC 접근 방식과 비교할 때 비현실적입니다.

어려움에도 불구하고, HTTP 프로토콜의 일관된 사용으로 인해 클라이언트 개발자가 쉽게 이해할 수있는 서비스가 있다는 이점이 있습니다. 하이퍼 미디어로 인해 서비스를 쉽게 검색 할 수 있어야하며 클라이언트는 서버 변경에 대해 매우 탄력적 이어야 합니다 .

하이퍼 미디어의 이점과 세션 상태를 피하면로드 밸런싱이 단순 해지고 서비스 분할이 가능해 집니다. HTTP 규칙을 엄격하게 준수하면 디버거 및 캐싱 프록시와 같은 도구를 사용할 수있게됩니다.

최신 정보

REST가 또 다른 '패션의 마지막 단어'인 것 같습니다 (또는 실제로 REST를 본 적이 없기 때문에 완전히 잘못 될 수 있습니다).

SOA 유형의 프로젝트를 수행하려는 사람들이 SOAP 스택을 사용하면 약속 된 이점을 실현하지 못한다는 사실을 알게 되었기 때문에 REST가 유행이되었다고 생각합니다. 사람들은 간단한 통합 방법론의 예로 웹을 계속 사용하고 있습니다. 불행히도 사람들은 웹을 만드는 데 필요한 계획과 예측의 양을 과소 평가한다고 생각하며 웹에서 발생하는 우연한 재사용을 허용하기 위해 수행해야 할 작업을 지나치게 단순화합니다.

실제로 REST를 본 적이 없지만 웹 브라우저를 사용하는 경우에는 사실이 아닙니다. 웹 브라우저는 REST 클라이언트입니다.

• 누군가 웹 사이트에서 일부 HTML을 변경할 때 브라우저 업데이트를 수행 할 필요가없는 이유는 무엇입니까?
• 왜 완전히 새로운 페이지 세트를 웹 사이트에 추가 할 수 있는데 "클라이언트"가 업데이트없이 새 페이지에 계속 액세스 할 수 있습니까?
• 웹 브라우저에 "service-description-language"를 제공 할 필요가없는 이유는 http://example.org/images/cat 로 이동하여 반환 유형이 jpeg 이미지가된다는 것을 알려주는 것입니다. 에 http://example.org/description/cat 반환 형식은 text / html과 것인가?
• 웹 브라우저를 사용하여 브라우저가 릴리스 될 때 존재하지 않은 사이트를 방문 할 수있는 이유는 무엇입니까? 고객이 이러한 사이트에 대해 어떻게 알 수 있습니까?

이 질문은 엉뚱한 질문처럼 들릴지 모르지만 답을 알고 있다면 REST가 무엇인지 알 수 있습니다. REST의 더 많은 이점은 StackOverflow를 참조하십시오. 질문을 볼 때 해당 페이지를 즐겨 찾기에 추가하거나 URL을 친구에게 보내면 동일한 정보를 볼 수 있습니다. 그는 해당 질문을 찾기 위해 사이트를 탐색 할 필요가 없습니다.

StackOverflow는 인증을 위해 다양한 OpenId 서비스를 사용하고 아바타 이미지를 위해 gravatar.com을 사용하고 분석 정보를 위해 Google 분석 및 Quantserve를 사용합니다. 이런 종류의 회사 간 통합은 SOAP 세계가 꿈꾸는 것 중 하나 입니다. 가장 좋은 예 중 하나는 StackOverflow UI를 구동하는 데 사용되는 jQuery 라이브러리가 Google의 콘텐츠 전송 네트워크에서 검색된다는 사실입니다. SO가 클라이언트 (예 : 웹 브라우저)가 타사 사이트에서 코드를 다운로드하도록 지시하여 성능을 향상시킬 수 있다는 사실은 웹 클라이언트와 서버 간의 낮은 연결에 대한 증거입니다.

이들은 작업중인 REST 아키텍처의 예입니다.

이제 일부 웹 사이트 / 응용 프로그램이 REST 규칙을 위반 한 후 브라우저가 예상대로 작동하지 않습니다.

• 악명 높은 뒤로 버튼 문제 는 서버 측 세션 상태를 사용하여 발생합니다.
• 서버 측 세션 상태가되면로드 밸런싱이 어려워 질 수 있습니다.
• Flash 응용 프로그램은 종종 URL이 구체적으로 표현을 식별하지 못하게합니다.
• 웹 브라우저를 손상시키는 다른 문제는 미디어 유형 표준을 준수하지 않는 것입니다. 우리는 IE6를 어떻게 죽여야하는지에 대해 항상 듣습니다. 문제는 표준이 제대로 따르지 않았거나 어떤 이유로 든 무시되었다는 것입니다.
• 로그인 세션의 사용은 많은 보안 허점의 원천입니다.

REST is everywhere. It is the part of the web that makes it work well. If you want to build distributed applications that can scale like the web, be resilient to change like the web and promote re-use as the web has done, then follow the same rules they did when building web browsers.

---

REST was kicked off, to my knowledge, by Roy Fielding's dissertation Architectural Styles and the Design of Network-based Software Architectures, which is worth a read if you haven't looked at it.

At the top of the dissertation is a quote:

Almost everybody feels at peace with nature: listening to the ocean waves against the shore, by a still lake, in a field of grass, on a windblown heath. One day, when we have learned the timeless way again, we shall feel the same about our towns, and we shall feel as much at peace in them, as we do today walking by the ocean, or stretched out in the long grass of a meadow.

— Christopher Alexander, The Timeless Way of Building (1979)

And that really does sum it up there. REST is in many ways more elegant.

SOAP is a protocol on top of HTTP, so it bypasses a lot of HTTP conventions to build new conventions in SOAP, and is in a number of ways redundant with HTTP. HTTP, however, is more than sufficient for retreiving, searching, writing, and deleting information via HTTP, and that's a lot of what REST is. Because REST is built with HTTP instead of on top of it, it also means that software that wants to integrate with it (such as a web browser) does not need to understand SOAP to do so, just HTTP, which has to be the most widely understood and integrated-with protocol in use at this point.

---

From here:

REST advantages:

• Lightweight - not a lot of extra xml markup
• Human Readable Results
• Easy to build - no toolkits required

Also check this out:

To be fair, REST isn't the best solution for every Web service. Data that needs to be secure should not be sent as parameters in URIs. And large amounts of data, like that in detailed purchase orders, can quickly become cumbersome or even out of bounds within a URI. In these cases, SOAP is indeed a solid solution. But it's important to try REST first and resort to SOAP only when necessary. This helps keep application development simple and accessible.

---

I can safely say I have spent a lot of time to understand this as a beginner but this is the best link to start with REST from scratch! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

Just to pull you in,

Think of what a "traditional web service" is. It is an interface with exposed "methods." Clients know the methods' name, input and output and hence can call them.

Now imagine an interface that does not expose "methods". Instead, it exposes "objects". So when a client sees this interface, all it sees is one or more "objects". "An object" has no input and output – because "it does not do anything". It is a noun, not a verb. It is "a thing", not "an action".

For example, think of a traditional web service that provides the current weather conditions if you provide it with a city. It probably has a web method like GetWeatherInfo() which takes a city as input and provides weather data as output. It is easy for you so far to understand how a client will consume this web service.

Now imagine, in the place of the above web service, there is a new one that exposes cities as objects. So, when you look at it as a client, instead of GetWeatherInfo(), you see New York, Dallas, Los Angeles, London and so on. And these cities do not have any application specific methods hanging from them - they are apparently like inert gases - they themselves do not react.

You must be thinking – well, how does that help you, as a client, to get to the weather of Dallas? We will get to that in a few moments.

If all you get from a web service is a "set of objects", obviously you need a way to "act on them". The objects themselves have no methods for you to call, so you need a set of actions that you can apply onto these objects. In other words, you need to "apply a verb to the noun". If you see an object, say, an apple, which is "a noun", you can apply "a verb" like eat, to it. But not all verbs can be applied to all nouns. Like, you can drive a car, but cannot drive a television.

Thus, if a web service exposes only objects, and you are asked – well, let us now design a few standard actions or verbs that "all clients can apply to all objects they see", ...

---

Here are some ideas:

• REST constrains your service to use a uniform interface. You don't have to waste time daydreaming (or arguing) about all of the possibly ways your service could work - you get right to work identifying the resources in your system. Turns out to be a big job in itself, but fortunately the problems tend to be much-better defined.
• With resources, their associations, and their representations in hand, there's really very little to do in implementing your service because many decisions have been made for you.
• Your system will look very much like other RESTful systems; learning curves for teammates, partners, and clients will be reduced.
• You'll have a common vocabulary to discuss design problems with other developers, and even with those less technically minded (such as customers).
• As Darrel says, because you're using a hypertext-driven design, your service narrows the scope of coupling to just one thing - media types. This helps you as a developer because changes to your system are contained within a narrow band of contact. This helps your clients in that fewer of your changes will break their code.
• Almost every problem you might have in implementing REST can be solved by exposing a new resource or re-thinking your resource model. This focus is, IMO, a big productivity boost.

Bottom line, REST removes many of the most time-consuming and contentious design and implementation decisions from your team's workflow. It shifts your attention from implementing your service to designing it. And it does so without piling gobbledygook onto the HTTP protocol.

---

Most of the "pro" answers about REST seem to come from people who have never developed a SOAP web service or client using an environment which supplies appropriate tools for the task. They complain about issues that I've simply never encountered, using Visual Studio .NET and IBM's Rational Web Developer. I suppose that if you have to develop web services or clients in a scripting language, or some other language with little or no tool support, that these are valid complaints.

I also have to admit that several of the "pro" points sound like things that might actually be true - but that I've never seen an example that illustrates their value. In particular, I'd greatly appreciate it if someone would post a comment containing a link to a good example of a REST web service. This should be one that uses multiple levels of resource, possibly in a hierarchy, and which uses media types properly. Maybe if I look at a good example, I'll understand, in which case, I'll come back here and admit it.

---

To add a slightly prosaic spin on to the answers already given the reason we use REST services where I am is that if you know you can hand a business partner a URL and know they will receive, in return, a nicely laid out slab of XML no matter whether they're working in .Net x.x, PHP, Python, Java, Ruby or god-knows-what it severely reduces headaches.

It also means that on the non-techy end our sales people can brag about our versatile API to people without fears of looking like complete muppets.

Much apart from the technical benefits anything it's easy for a non-techy to explain, demonstrate and feel confident about is a good thing. SOAP, although just as cool for techies is far less approachable by the non-techies and therefore isn't as easy to "sell".

I tend to notice that things non-techies can get their head round tend to stick. So I doubt REST as a technique is liable to be as susceptible as SOAP to the whims of fashion.

But all the stuff about not putting anything in a REST service that should be locked down is double true if only because the technology's so easily understood by people who aren't so technically minded.

---

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.

In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture. REST is not a "standard". There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often "roll your own" with standard library features in languages like Perl, Java, or C#.

참고URL : https://stackoverflow.com/questions/1368014/why-do-we-need-restful-web-services