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

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

Wikipedia에서 몇 가지 정보를 읽었으며 Sun Developer Network에서 REST에 대한 기사도 읽었으며 이것이 쉬운 기술이 아니라 RESTful 앱을 구축하기위한 특별한 프레임 워크가 있으며 SOAP 웹 서비스와 비교되는 경우가 많다는 것을 알았습니다. 프로그래머는 SOAP를 사용할 때와 REST가 좋은 방법이 될 수있는 때를 이해해야합니다.

몇 년 전 SOAP는 매우 인기가 있었고 (멋진?) 모든 좋은 CV에 '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을 변경할 때 브라우저 업데이트를 수행 할 필요가없는 이유는 무엇입니까?
• 웹 사이트에 완전한 새 페이지 세트를 추가 할 수 있고 "클라이언트"가 업데이트 없이도 새 페이지에 계속 액세스 할 수있는 이유는 무엇입니까?
• http://example.org/images/cat 로 이동할 때 반환 유형이 jpeg 이미지가 될 것임을 알리기 위해 웹 브라우저에 "service-description-language"를 제공 할 필요가없는 이유는 무엇입니까? 에 http://example.org/description/cat 반환 형식은 text / html과 것인가?
• 웹 브라우저를 사용하여 브라우저가 출시되었을 때 존재하지 않았던 사이트를 방문 할 수있는 이유는 무엇입니까? 클라이언트는 이러한 사이트에 대해 어떻게 알 수 있습니까?

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

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

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

이제 일부 웹 사이트 / 애플리케이션이 REST의 규칙을 어 기고 브라우저가 예상대로 작동하지 않습니다.

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

REST는 어디에나 있습니다. 잘 작동하는 것은 웹의 일부입니다. 웹처럼 확장 할 수있는 분산 애플리케이션을 구축하고, 웹처럼 변화에 탄력적으로 대응하고, 웹처럼 재사용을 촉진하려면 웹 브라우저를 구축 할 때와 동일한 규칙을 따르십시오.

REST는 내가 아는 한 Roy Fielding의 논문 Architectural Styles and the Design of Network-based Software Architectures 에 의해 시작되었으며, 아직 보지 않았다면 읽을 가치가 있습니다.

논문 상단에 인용문이 있습니다.

거의 모든 사람들이 자연과 평화를 느낍니다. 해안, 고요한 호수, 잔디밭, 바람에 날리는 히스에서 파도 소리를 듣습니다. 언젠가 우리가 시간을 초월한 길을 다시 배웠을 때, 우리는 우리 마을에 대해 똑같이 느낄 것이며, 오늘날 우리가 바다를 걷거나 긴 풀에 뻗어있는 것처럼 그들에서도 평화를 느낄 것입니다. 목초지.

— 크리스토퍼 알렉산더, Timeless Way of Building (1979)

그리고 그것은 실제로 그것을 요약합니다. REST는 여러면에서 더 우아합니다.

SOAP는 HTTP를 기반으로하는 프로토콜이므로 많은 HTTP 규칙을 우회하여 SOAP에서 새로운 규칙을 구축하고 여러 가지 방법으로 HTTP와 중복됩니다. 그러나 HTTP는 HTTP를 통해 정보를 검색, 작성 및 삭제하는 데 충분하며 REST가 많은 것입니다. REST는 HTTP가 아닌 HTTP로 빌드되기 때문에 웹 브라우저와 같이 통합하려는 소프트웨어가이를 수행하기 위해 SOAP를 이해할 필요가 없으며 HTTP 만 이해할 필요가 있습니다. 이 시점에서 널리 이해되고 프로토콜과 통합되었습니다.

에서 여기 :

REST 장점 :

• 경량-추가 xml 마크 업이 많지 않음
• 사람이 읽을 수있는 결과
• 간편한 구축-툴킷이 필요하지 않음

또한 이것을 확인 하십시오 :

공정하게 말하면 REST는 모든 웹 서비스에 대한 최상의 솔루션은 아닙니다. 보안이 필요한 데이터는 URI의 매개 변수로 보내서는 안됩니다. 그리고 상세한 구매 주문서와 같이 대량의 데이터는 URI 내에서 빠르게 번거 롭거나 심지어 범위를 벗어날 수 있습니다. 이러한 경우 SOAP는 실제로 견고한 솔루션입니다. 그러나 REST를 먼저 시도하고 필요할 때만 SOAP를 사용하는 것이 중요합니다. 이를 통해 애플리케이션 개발을 간단하고 쉽게 액세스 할 수 있습니다.

초보자로서 이것을 이해하기 위해 많은 시간을 보냈다고 안전하게 말할 수 있지만 이것은 처음부터 REST로 시작하는 가장 좋은 링크입니다! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

당신을 끌어 들이기 위해

"전통적인 웹 서비스"가 무엇인지 생각해보십시오. 노출 된 "메서드"가있는 인터페이스입니다. 클라이언트는 메소드의 이름, 입력 및 출력을 알고 있으므로이를 호출 할 수 있습니다.

이제 "메서드"를 노출하지 않는 인터페이스를 상상해보십시오. 대신 "객체"를 노출합니다. 따라서 클라이언트가이 인터페이스를 볼 때 보는 것은 하나 이상의 "객체"입니다. "객체"에는 입력과 출력이 없습니다. "아무것도하지 않기 때문입니다." 동사가 아니라 명사입니다. 그것은 "행동"이 아니라 "사물"입니다.

예를 들어, 도시를 제공하는 경우 현재 기상 조건을 제공하는 전통적인 웹 서비스를 생각해보십시오. 도시를 입력으로 사용하고 날씨 데이터를 출력으로 제공하는 GetWeatherInfo ()와 같은 웹 메서드가있을 수 있습니다. 지금까지 클라이언트가이 웹 서비스를 어떻게 사용하는지 이해하는 것은 쉽습니다.

이제 위의 웹 서비스 대신 도시를 객체로 노출하는 새로운 서비스가 있다고 상상해보십시오. 따라서 GetWeatherInfo () 대신 클라이언트로 보면 New York, Dallas, Los Angeles, London 등이 표시됩니다. 그리고이 도시들은 그들 자신이 반응하지 않는 불활성 가스와 같은 특별한 방법을 가지고 있지 않습니다.

당신은 생각해야합니다 – 글쎄요, 그것이 당신이 클라이언트로서 달라스의 날씨에 도달하는 데 어떻게 도움이됩니까? 우리는 잠시 후에 그것에 대해 알아볼 것입니다.

웹 서비스에서 얻는 것이 "객체 집합"뿐이라면 당연히 "객체에 대한 조치"방법이 필요합니다. 개체 자체에는 호출 할 메서드가 없으므로 이러한 개체에 적용 할 수있는 일련의 작업이 필요합니다. 즉, "명사에 동사를 적용"해야합니다. 예를 들어 "명사"인 사과와 같은 대상을 보면 eat와 같은 "동사"를 적용 할 수 있습니다. 그러나 모든 동사가 모든 명사에 적용될 수있는 것은 아닙니다. 자동차를 운전할 수는 있지만 텔레비전은 운전할 수 없습니다.

따라서 웹 서비스가 객체 만 노출하고 질문을받는 경우-이제 "모든 클라이언트가 자신이 보는 모든 객체에 적용 할 수있는"몇 가지 표준 동작 또는 동사를 설계 해 보겠습니다.

다음은 몇 가지 아이디어입니다.

• REST는 서비스가 균일 한 인터페이스를 사용하도록 제한합니다. 서비스가 작동 할 수있는 모든 방법에 대해 공상 (또는 논쟁)하는 데 시간을 낭비 할 필요가 없습니다. 시스템에서 리소스를 식별하는 작업을 바로 수행 할 수 있습니다. 그 자체로 큰 일로 밝혀졌지만 다행히도 문제는 훨씬 더 잘 정의되는 경향이 있습니다.
• 리소스, 연관성 및 표현을 사용하면 많은 결정을 내렸기 때문에 서비스를 구현할 때 할 일이 거의 없습니다.
• 시스템은 다른 RESTful 시스템과 매우 유사합니다. 팀원, 파트너 및 고객의 학습 곡선이 줄어들 것입니다.
• 다른 개발자는 물론 기술적 인 생각이 덜한 개발자 (예 : 고객) 와도 디자인 문제를 논의 할 수있는 공통 어휘를 갖게됩니다.
• Darrel이 말했듯이 하이퍼 텍스트 기반 디자인을 사용하고 있기 때문에 서비스는 결합 범위를 미디어 유형 중 하나로 좁 힙니다. 시스템 변경 사항이 협소 한 범위 내에 포함되기 때문에 개발자에게 도움이됩니다. 이렇게하면 고객의 변경 사항이 적어 코드가 손상 될 수 있습니다.
• REST를 구현할 때 발생할 수있는 거의 모든 문제 는 새 자원 을 노출 하거나 자원 모델을 다시 생각하여 해결할 수 있습니다 . 이 초점은 IMO, 큰 생산성 향상입니다.

요컨대 REST는 팀의 워크 플로우에서 가장 시간이 많이 걸리고 논쟁이되는 설계 및 구현 결정을 제거합니다. 서비스 구현 에서 디자인으로 주의를 이동합니다 . 그리고 그것은 HTTP 프로토콜에 멍청이를 쌓지 않고 그렇게합니다.

REST에 대한 대부분의 "프로"답변은 작업에 적합한 도구를 제공하는 환경을 사용하여 SOAP 웹 서비스 또는 클라이언트를 개발 한 적이없는 사람들로부터 나온 것 같습니다. 그들은 Visual Studio .NET과 IBM의 Rational Web Developer를 사용하여 내가 결코 만난 적이없는 문제에 대해 불평합니다. 스크립팅 언어 또는 도구 지원이 거의 또는 전혀없는 다른 언어로 웹 서비스 나 클라이언트를 개발해야한다면 이것이 유효한 불만이라고 생각합니다.

또한 몇 가지 "장점"포인트가 실제로 사실 일 수있는 것처럼 들린다는 점을 인정해야합니다. 그러나 그 가치를 보여주는 예는 본 적이 없습니다. 특히 누군가가 REST 웹 서비스의 좋은 예에 대한 링크가 포함 된 댓글을 게시한다면 대단히 감사하겠습니다. 이는 계층 구조에서 여러 수준의 리소스를 사용하고 미디어 유형을 올바르게 사용하는 것이어야합니다. 좋은 예를 보면 이해할 수있을 것입니다. 어떤 경우에는 여기로 돌아와서 인정할 것입니다.

우리가 REST 서비스를 사용하는 이유를 고려하여 이미 답변에 약간 산발적 인 회전을 추가하려면 비즈니스 파트너에게 URL을 제공 할 수 있고 그 대가로 멋지게 배치 된 XML 슬래브를받을 수 있다는 것을 알고 있기 때문입니다. 그들이 .Net xx, PHP, Python, Java, Ruby 또는 God-knows에서 일하든 상관없이 두통을 심각하게 줄여줍니다.

이는 또한 비 기술적 인 측면에서 영업 담당자가 완전한 머펫처럼 보일 까봐 두려워하지 않고 다용도 API를 사람들에게 자랑 할 수 있음을 의미합니다.

기술적 인 이점을 제외하고 비전문가가 쉽게 설명하고 보여주고 자신감을 느끼는 것은 좋은 일입니다. SOAP는 기술자에게는 멋지지만 기술자가 아닌 사람에게는 접근하기가 훨씬 어렵 기 때문에 "판매"하기가 쉽지 않습니다.

나는 비전문가가 머리를 빙글 빙글 돌릴 수있는 것이 달라 붙는 경향이 있다는 것을 알아 차리는 경향이 있습니다. 그래서 저는 REST가 패션의 변덕에 SOAP만큼이나 민감하기 쉬운 기술로 의심됩니다.

그러나 잠 가야 할 REST 서비스에 아무것도 넣지 않는 것에 대한 모든 것은 기술적으로 그렇게 생각하지 않는 사람들이 기술을 쉽게 이해할 수 있기 때문에 두 배 사실입니다.

REST는 네트워크 애플리케이션을 설계하기위한 아키텍처 스타일입니다. 아이디어는 CORBA, RPC 또는 SOAP와 같은 복잡한 메커니즘을 사용하여 시스템간에 연결하는 대신 간단한 HTTP를 사용하여 시스템간에 호출을 수행한다는 것입니다.

여러면에서 HTTP 기반의 World Wide Web 자체는 REST 기반 아키텍처로 볼 수 있습니다. RESTful 애플리케이션은 HTTP 요청을 사용하여 데이터를 게시 (생성 및 / 또는 업데이트)하고, 데이터를 읽고 (예 : 쿼리 작성), 데이터를 삭제합니다. 따라서 REST는 4 개의 모든 CRUD (Create / Read / Update / Delete) 작업에 HTTP를 사용합니다.

REST는 RPC (원격 프로 시저 호출) 및 웹 서비스 (SOAP, WSDL 등)와 같은 메커니즘에 대한 경량 대안입니다. 나중에 REST가 얼마나 더 간단한 지 살펴 보겠습니다.

간단하지만 REST는 모든 기능을 갖추고 있습니다. 기본적으로 RESTful 아키텍처로는 할 수없는 웹 서비스에서 할 수있는 일은 없습니다. REST는 "표준"이 아닙니다. 예를 들어 REST에 대한 W3C 권장 사항은 없습니다. REST 프로그래밍 프레임 워크가 있지만 REST로 작업하는 것은 매우 간단하여 Perl, Java 또는 C #과 같은 언어로 표준 라이브러리 기능을 사용하여 "자신 만의"롤링을 할 수 있습니다.