Netflix 또는 Twitter 스타일 웹 서비스가 REST 또는 SOAP를 사용해야합니까?

Netflix 또는 Twitter 스타일 웹 서비스가 REST 또는 SOAP를 사용해야합니까? [닫은]

---

Twitter와 Netflix라는 두 가지 REST 서비스를 구현했습니다. 두 경우 모두, 이러한 서비스를 SOAP 대신 REST로 공개하기로 한 결정과 관련된 사용 및 논리를 찾기 위해 고심했습니다. 누군가 내가 누락 된 것을 알아낼 수 있고 REST가 이러한 서비스의 서비스 구현으로 사용 된 이유를 설명 할 수 있기를 바랍니다.

1. REST 서비스를 구현하는 데 SOAP 서비스를 구현하는 것보다 시간이 오래 걸립니다. 모든 현대 언어 / 프레임 워크 / 플랫폼이 WSDL에서 읽고 프록시 클래스와 클라이언트를 출력하는 도구가 있습니다. REST 서비스 구현은 수작업으로 수행되며이를 통해 문서를 읽으십시오. 또한이 두 가지 서비스를 구현하는 동안 실제 스키마 나 참조 문서가 없기 때문에 파이프를 통해 무엇이 돌아올 지에 대해 "추측"해야합니다.

2. 어쨌든 XML을 반환하는 REST 서비스를 작성해야하는 이유는 무엇입니까? 유일한 차이점은 REST를 사용하면 각 요소 / 속성이 나타내는 유형을 알지 못한다는 것입니다. 자신의 구현을 통해 언젠가는 항상 int라고 생각한 필드에서 문자열이 나오지 않기를 바랍니다 . SOAP는 WSDL을 사용하여 데이터 구조를 정의하므로 이는 쉬운 일이 아닙니다.

3. SOAP를 사용하면 SOAP Envelope의 "오버 헤드"가 있다는 불만을 들었습니다. 이 시대에 우리는 실제로 몇 바이트에 대해 걱정할 필요가 있습니까?

4. REST를 사용하면 URL을 브라우저에 넣고 데이터를 볼 수 있다는 주장을 들었습니다. REST 서비스가 단순 인증을 사용하거나 인증을 사용하지 않는 경우에는 물론입니다. 예를 들어 Netflix 서비스는 OAuth를 사용하므로 요청을 제출하기 전에 서명하고 인코딩해야합니다.

5. 각 리소스에 대해 "읽을 수있는"URL이 필요한 이유는 무엇입니까? 서비스를 구현하기 위해 도구를 사용하는 경우 실제 URL에 관심이 있습니까?

---

탄광에서 카나리아.

나는 이런 질문을 1 년 가까이 기다리고있었습니다. 오늘이 올 것이 불가피했고 앞으로 몇 달 안에 더 많은 질문을 보게 될 것입니다.

경고 표시

SOAP 클라이언트보다 RESTful 클라이언트를 빌드하는 데 시간이 오래 걸립니다. SOAP 툴킷은 많은 상용구 코드를 제거하고 거의 노력없이 클라이언트 프록시 객체를 사용할 수있게합니다. Visual Studio와 같은 도구 및 서버 URL을 사용하면 5 분 이내에 로컬로 임의의 복잡한 원격 개체에 액세스 할 수 있습니다.

application / xml 및 application / json을 반환하는 서비스는 클라이언트 개발자에게 성가시다. 우리는 그 데이터를 어떻게 처리해야합니까?

다행스럽게도 REST 서비스를 제공하는 많은 사이트는 많은 클라이언트 라이브러리를 제공하므로 이러한 라이브러리를 사용하여 강력한 형식의 개체에 액세스 할 수 있습니다. 그래도 바보 같은 것 같습니다. 그들이 SOAP를 사용했다면 우리는 그 프록시 클래스를 직접 코드 생성 할 수있을 것이다.

SOAP 오버 헤드, ha. 대기 시간이 줄어 듭니다. 사람들이 실제로 초과 바이트 수를 걱정하고 있다면 HTTP가 올바른 선택이 아닐 수도 있습니다. 사용자 에이전트 헤더가 몇 바이트를 사용하는지 보셨습니까?

예, 웹 브라우저를 HTML 및 자바 스크립트 이외의 다른 디버깅 도구로 사용해 보셨습니까? 짜증나게 해줘 동사 중 두 개만 사용할 수 있으며 캐싱은 끊임없이 방해를받으며 오류 처리는 많은 정보를 삼키며 끊임없이 favicon.ico를 찾고 있습니다. 날 쏴

읽을 수있는 URL. 명사 만, 동사는 없어요 예, CRUD 작업 만 수행하는 한 간단하고 한 가지 방식으로 개체 계층 구조에만 액세스하면됩니다. 불행히도 대부분의 응용 프로그램은 그보다 약간 더 많은 기능이 필요합니다.

임박한 재앙

현재 동일한 결론을 내리는 REST 서비스와 통합되는 애플리케이션을 개발중인 개발자의 메트릭 보트로드가 있습니다. 그들은 단순성, 융통성, 확장 성, 진 화성 및 평온한 재사용의 성배를 약속 받았다. 웹 자체의 특성은 어떻게 잘못 될 수 있습니까?

그러나 그들은 버저 닝이 문제의 많은 부분을 발견하고 있지만 컴파일러는 문제를 감지하는 데 도움이되지 않습니다. 수작업으로 작성된 클라이언트 코드는 데이터 구조가 발전하고 URL이 리팩토링됨에 따라 유지 보수가 어렵다. 명사와 4 개의 동사를 중심으로 API를 디자인하는 것은 특히 어려울 수 있습니다. 특히 쿼리 문자열을 사용할 수 있거나 사용할 수없는시기를 알려주는 RESTful Url zealots가 있습니다.

개발자는 왜 Json 형식과 Xml 형식을 모두 지원하기 위해 노력을 낭비하고 있는지 궁금해 할 것입니다. 왜 노력을 하나에 집중하고 잘 수행하지 않습니까?

상황이 어떻게 잘못 되었나요

내가 뭘 잘못했는지 말해 줄게 우리는 개발자로서 마케팅 부서가 우리의 주요 약점을 활용할 수 있도록합니다. 은 총알에 대한 우리의 영원한 수색은 REST가 실제로 무엇인지에 대한 실명을 보여주었습니다. 표면적으로 REST는 너무 쉽고 간단 해 보입니다. Urls로 리소스 이름을 지정하고 GET, PUT, POST 및 DELETE를 사용하십시오. 우리는 이미 그 방법을 알고 있습니다. SELECT, INSERT, UPDATE 및 DELETE가있는 테이블과 열 및 SQL 문이있는 데이터베이스를 수년간 처리 해 왔습니다. 케이크 한 조각이었을 것입니다.

자체 설명 및 하이퍼 미디어 제한과 같은 일부 사람들이 논의하는 REST의 다른 부분이 있지만 이러한 제한은 자원 식별 및 균일 한 인터페이스만큼 단순하지 않습니다. 원하는 목표가 단순 할 경우 복잡성을 더하는 것 같습니다.

이 워터 다운 버전의 REST는 여러 가지 방법으로 개발자 문화에서 검증되었습니다. 리소스 식별과 균일 한 인터페이스를 장려하는 서버 프레임 워크가 만들어졌지만 다른 제약 조건은 지원하지 않았습니다. 접근 방식을 차별화하는 용어가 사용되기 시작했습니다 (HI-REST vs LO-REST, Corporate REST vs Academic REST, REST vs RESTful).

어떤 사람들은 모든 제약 조건을 적용하지 않으면 REST가 아니라고 소리를 지 릅니다. 혜택을받지 못할 것입니다. 반 REST는 없습니다. 그러나 그 목소리는 그들의 소중한 용어가 모호함에서 도난 당하여 주류가되었다는 화가 난 종교적 열성 자로 분류되었습니다. REST 사운드를보다 어렵게 만드는 질투하는 사람들.

REST라는 용어는 분명히 주류가되었습니다. API가있는 거의 모든 주요 웹 속성은 "REST"를 지원합니다. 트위터와 넷플릭스는 매우 유명한 두 가지입니다. 가장 무서운 점은 내가 설명하는 공개 API 하나만 생각할 수 있으며 하이퍼 미디어 제약 조건을 실제로 구현하는 소수가 있다는 것입니다. StackOverflow 및 Gowalla와 같은 일부 사이트는 응답에서 링크를 지원하지만 링크에는 큰 차이가 있습니다. StackOverflow API에는 루트 페이지가 없습니다. 웹 사이트에 대한 홈 페이지가 없다면 웹 사이트가 얼마나 성공적 이었을지 상상해보십시오!

당신은 내가 두려워 두려운

지금까지 작성한 경우 귀하의 질문에 대한 짧은 대답은 API (Netflix 및 Twitter)가 모든 제약 조건을 준수하지 않으므로 REST API가 가져 오는 이점을 얻지 못할 것입니다.

REST 클라이언트는 SOAP 클라이언트보다 빌드 시간이 오래 걸리지 만 하나의 특정 서비스와 연결되어 있지 않으므로 여러 서비스에서 재사용 할 수 있어야합니다. 웹 브라우저의 고전적인 예를 들어보십시오. 웹 브라우저는 몇 개의 서비스에 액세스 할 수 있습니까? 피드 리더는 어떻습니까? 이제 평균 트위터 클라이언트가 몇 개의 다른 서비스에 액세스 할 수 있습니까? 예, 하나 만요

REST 클라이언트는 단일 서비스와 인터페이스하도록 구축되어서는 안되며 모든 서비스가 제공 할 수있는 특정 미디어 유형을 처리하도록 구축되어야합니다. 명백한 질문은 application / json 또는 application / xml을 제공하는 서비스를 위해 REST 클라이언트를 어떻게 구축 할 수 있는가하는 것입니다. 당신은 할 수 없습니다. 이는 해당 형식이 REST 클라이언트에 완전히 쓸모 없기 때문입니다. 당신이 직접 말 했어요

you have to make "guesses" as to what will come back across the pipe as there is no real schema or reference document

You are absolutely correct for services like Twitter. However, the self-descriptive constraint in REST says that the HTTP content type header should describe exactly the content that is being transmitted across the wire. Delivering application/json and application/xml tells you nothing about the content.

When it comes to considering the performance of REST based systems it is necessary look at the bigger picture. Talking about envelope bytes is like talking about loop unwinding when comparing a quick-sort to a shell-sort. There are scenarios where SOAP can perform better, and there are scenarios where REST can perform better. Context is everything.

REST gains much of its performance advantage by being very flexible about what media types it supports and by having sophisticated support for caching. For caching to work well though nearly all of the constraints must be adhered to.

Your last point about readable urls is by far the most ironic. If you truly commit to the hypermedia constraint, then every URL could be a GUID and the client developer would lose nothing in readability.

The fact that URIs should be opaque to the client is one of the most key things when developing REST systems. Readable URLs are convenient for the server developer and well structured URLs make it easier for the server framework to dispatch requests, but those are implementation details that should have no impact on the developers consuming the API.

The Twitter API is not even close to being RESTful and that is why you are unable to see any benefit to using it over SOAP. The Netflix API is much closer but it’s use of generic media types demonstrates that failing to adhere to even a single constraint can have a profound impact on the benefits derived from the service.

It may not be all their fault

I’ve done a whole lot of dumping on the service providers, but it takes two to dance RESTfully. A service may follow all of the constraints religiously and a client can still easily undo all of the benefits.

If a client hard codes urls to access certain types of resources then it is preventing the server from changing those urls. Any kind URL construction based on implicit knowledge of how the service structures its urls is a violation.

Making assumptions about what type of representation will be returned from a link can lead to problems. Making assumptions about the content of the representation based on knowledge that is not explicitly stated in the HTTP headers is definitely going to create coupling that will cause pain in the future.

Should they have used SOAP?

Personally, I don’t think so. REST done right allows a distributed system to evolve over the long term. If you are building distributed systems that have components that are developed by different people and need to last for many years, then REST is a pretty good option.

---

SOAP is an object-oriented, remote procedure call technology stack. It works by building a new abstraction on top of an existing protocol (HTTP).

REST is a document oriented approach, that simply uses the features of an existing protocol (HTTP). "REST" is just a buzzword -- the concept is this: Just use the web the way it was designed to work!

In response to edits to question:

1. "Implementing a REST service takes infinitely longer than implementing a SOAP service."

   Um, no, it can't be infinitely longer. And in cases where what you are trying to retrieve is already a document or file, it's actually much faster. For example, the OGC spec for WMS (Web Mapping Service) defines both a SOAP and REST version of the protocol, and there's a reason why almost nobody implements the SOAP version -- it's because if you're trying to get a map, it's a lot easier to just build a URL and fetch image bytes from that URL than it is to bother with encapsulating it into a SOAP message. But yes, I will agree that if the point of the web service is to transfer some strongly-typed object in a domain object model, SOAP is better suited for that use.

2. "Why write a REST service that returns XML anyway?"

   Well, yes, that can be silly. But it depends on what the XML is. If there's a clearly defined schema for it somewhere, then there's no ambiguity. For example, you can think of WSDL URLs as being a kind of RESTful web service for retrieving information about a web service. In this case, adding the overhead of another SOAP request would be pointless.

   In general, REST wins when the content that is being transferred can be thought of as a file, as a single unit. SOAP wins when the content needs to be treated as an object with members.

3. "I've heard the complaint that with SOAP you have the "overhead" of the SOAP Envelope. In this day and age, do we really need to worry about a handful of bytes?"

   Yes. Not in every circumstance, but there are sites with a great deal of traffic where it makes a difference. Is it enough of a difference to outweigh the semantic differences of using SOAP instead of REST? I doubt it. If you're doing an object remoting protocol and the number of bytes is making a difference, SOAP is probably not the tool for you anyway -- maybe you should be using CORBA or DCOM instead.

4. "I've heard the argument that with REST you can just pop the URL into the browser and see the data."

   Yes, and this is a large argument in favor of REST if it makes sense to view the data in a browser. For example, with image data, it's an easy way to debug the service -- just paste the URL into your browser's address bar and see what the image looks like. Or if the data returned is in XML, and you have a referenced XML stylesheet that renders into readable HTML in the browser, then you get the benefit of semantic markup and easy visualization all in one package. But you are correct, this benefit mostly evaporates when working with more complex authentication schemes. If you can't encode all your authentication information into each HTTP request, then I would argue that it doesn't count as REST at all.

5. "Why do we need a "readable" URL for each resource? If we were using a tool to implement the service, do we really care about the actual URL?"

   Well, it depends. Why do we need readable URLs for any resource on the web? You can read Tim Berners-Lee's essay Cool URIs Don't Change for the rationale, but basically, as long as the resource may still be useful in the future, the URI for that resource should stay the same.

   Obviously, for transient resources (like the "today's Money" link in the essay) there is no need for it, since the need to reference the resource goes away if the corresponding resource goes away. But for more permanent resources (like StackOverflow questions, for example, or movies on IMDB), you want to have a URL that will work forever. When you're designing a web service, you need to decide if the resources themselves could outlive your service, and if so, then REST is probably the right way to go.

For the record, yes, I've been developing web pages since well before NetFlix or Twitter existed. And no, I've not yet had any need or opportunity to implement a client to either NetFlix or Twitter's services. But even if their services are atrociously difficult to work with, that doesn't mean the technology they implemented their services on top of is bad -- only that those two implementations are bad.

To make a long story short: REST and SOAP are just tools. They each have strengths and weaknesses. If the only tool you have is a hammer, then every problem looks like a nail. So get to know both tools, and learn how to use them correctly, and then choose the right tool for each job.

---

An honest question deserves an honest answer. But first, why did you use the text of this question as an answer to another question if you did not think it was rhetorical in nature?

Anyway:

1. "Tools exist for all modern languages/frameworks/platforms to read in a WSDL and output proxy classes and clients. Implementing a REST service is done by hand by reading documentation."

   Just like browser vendors have read and re-read the HTML 4.01 specification up and down to try to implement a consistent browsing experience. Have you reflected on the fact that browsers were invented long before internet banking and stackoverflow, and yet, you can use a browser to do just those things. This is made possible because of the sole reason that everybody agrees to use HTML (and related formats like CSS, JS, JPEG etc).

   Blogging is actually not that new, and someone came up with AtomPub, which allows any blogging software to access and update posts in a blog, much like any web browser can access any web page. That's pretty neat, and works because of the RESTful constraints imposed by the protocol.

   But for Twitter and Netflix, there is no universal agreement that "all microblogs in existence shall use the media type application/tweet", mainly because microblogging is so new. Maybe in a few years time a few microblogging services settle on the same API so that Twitter, Facebook, Identica and can interoperate. None of their existing APIs are anywhere near RESTful, however much they claim, so I don't expect it to happen real soon.

   "Furthermore, while implementing these two services, you have to make "guesses" as to what will come back across the pipe as there is no real schema or reference document."

   You've hit the nail on the head. REST is all about distributed and hypermedia, and that pretty much sums it up. A browser looks at what it gets from a request and shows it to the user. A HTML page usually spawns a lot more GET requests, for example CSS, scripts and images. An image is typically only rendered to the screen, JavaScript is executed, and so on. Each time, the browser does what it does because it found the link in an <img> or <style> tag and the response media type was image/jpeg or text/css.

   If Twitter makes a hypermedia based API, it will probably always return an application/tweet every time you follow a link to a tweet, but the client should never assume it, and always check what it gets before acting on it.

2. "Why write a REST service that returns XML anyway?"

   This all boils down to media types. Like HTML, if you see an element that you've no idea what actually means, the HTML spec instructs you to ignore them, and process the "body" of the tag if it has one. Likewise, the atom spec instructs you to ignore unknown elements and foreign markup (from different namespaces) and not process the body (IIRC).

   Designing media types for generic problem domains (as in the HTML media type for the rich text problem domain) is very hard. Making media types for very narrow problem domains is probably a lot easier (like a tweet). But it's always a good idea to design for extensibility and specify how clients (and servers) are supposed to react when they see elements or data items that don't match the spec. JPEG, for example has an Application-specific record type (e.g. APP1) which is used to contain all sorts of meta data.

3. "I've heard the complaint that with SOAP you have the "overhead" of the SOAP Envelope. In this day and age, do we really need to worry about a handful of bytes?"

   No, we don't. REST is absolutely not about being efficient over the wire, it's actually trading wire efficiency in. REST's efficiency comes from the possibilities of caching enabled by all the other constraints: Fielding's dissertation notes: The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction. I don't think that the SOAP Envelope byte count overhead is a valid concern.

4. "I've heard the argument that with REST you can just pop the URL into the browser and see the data."

   Yes, that's also an invalid argument. It doesn't work that way. Even if it did work, most narrow REST APIs out there use media types that browsers have no idea about and it still won't work.

   But there are a lot more possibilities than a browser to test a HTTP based API, like command line utilities or browser extensions that allow you to control almost any aspect of a HTTP request, inspect response headers and discover links for you to follow. But even so, this is nowhere near as easy as generating WSDL stubs and making a three line program to call the function anyway.

5. "Why do we need a "readable" URL for each resource? If we were using a tool to implement the service, do we really care about the actual URL?"

   If you look at how the web works, I'm pretty sure that humans are by and large glad that the URI for a wikipedia page looks like this, http://en.wikipedia.org/wiki/Stack_overflow instead of http://en.wikipedia.org/wiki/?oldid=376349090. But it actually is not important to REST. The important thing to try to get right is to choose to place relevant data in the URI that is not likely to change. You might think that the database ID will never change, but what happens when two data sets need to be merged? All your primary keys change. The page title (Stack_overflow) will not change.

Sorry for the long response, but I believe this question is valid, and hasn't been addressed before here on SO. I'm sure Darrel Miller will add his answer once he's back too.

Edit: formatting

---

Martin Fowler has a post on the Richardson Maturity Model which does a great job explaining the difference between SOAP and REST.

---

WSDL and other document level protocols are redundant. The HTTP protocol supports a much richer set of operations besides just serving documents and submitting forms.

Supporters of REST are uncomfortable with that redundancy.

참고URL : https://stackoverflow.com/questions/3285704/should-a-netflix-or-twitter-style-web-service-use-rest-or-soap