Übersetzung vorschlagen
 
Andere Vorschläge:

progress indicator
Keine anderen Vorschläge
MSDN Magazin > Home > Ausgaben > 2009 > MSDN Magazin Juli 2009 >  Service Station: Weitere Informationen zu REST
Inhalt anzeigen: Englisch mit deutscher ÜbersetzungInhalt anzeigen: Englisch mit deutscher Übersetzung
Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden.
Service Station
More On REST
Jon Flanders
In the last two columns, I've described the basics of REST and talked about exposing and consuming Web feeds. In this column, I'll answer a number of questions that often come up when I make presentations or conduct training sessions on using REST to build service-based applications.

Which is better, REST or SOAP?
This is one of the most common questions I get about REST, and it is probably the least fair. Both REST and SOAP are often termed "Web services," and one is often used in place of the other, but they are totally different approaches. REST is an architectural style for building client-server applications. SOAP is a protocol specification for exchanging data between two endpoints.
Comparing REST with the remote procedure call (RPC) style of building client-server applications would be more accurate. RPC is a style (rather than a protocol, which is what SOAP is) of building client-server applications in which a proxy (generally generated from metadata) is used in the client's address space to communicate with the server and the proxy's interface mimics the server's interface. Although SOAP doesn't require the RPC style, most modern SOAP toolkits are geared toward (at least they default to) using RPC.
In contrast to RPC, REST lacks the metadata-generated proxy (see the next question for more information), which means that the client is less coupled to the service. Also, because REST relies on the semantics of HTTP, requests for data (GET requests) can be cached. RPC systems generally have no such infrastructure (and even when performing RPC using SOAP over HTTP, SOAP responses can't be cached because SOAP uses the HTTP POST verb, which is considered unsafe). SOAP intentionally eschews HTTP, specifically to allow SOAP to work over other protocols, so it's actually a little disingenuous to call SOAP-based services Web services.
My perspective is that both REST and SOAP can be used to implement similar functionality, but in general SOAP should be used when a particular feature of SOAP is needed, and the advantages of REST make it generally the best option otherwise.

What about security? Isn't SOAP more secure than REST?
This question touches one of my pet peeves because the answer is clearly no. It is just as easy to make a RESTful service secure as it is to make a SOAP-based service secure. In the majority of cases involving either REST or SOAP, the security system is the same: some form of HTTP-based authentication plus Secure Sockets Layer (SSL). Although technically the technology for secure conversations over HTTP is now called Transport Layer Security (TLS), SSL is still the name most commonly used.
What is true is that a SOAP-based service, because of the extra protocols specified in the various WS-* specifications, does support end-to-end message security. This means that if you pass SOAP messages from endpoint to endpoint to endpoint, over the same or different protocols, the message is secure. If your application needs this particular feature, SOAP plus WS-* is definitely the way to go. REST probably wouldn't be an option here because of its dependence on HTTP, and inherently you'd be designing a multiprotocol application. I believe that the fact that SOAP with WS-* enables end-to-end message-level security is the source of the misconception that SOAP-based services are more secure than RESTful services.
Another area in which the WS-* folks have spent a lot of time and effort recently is federated security. The simple idea behind federated identity is to create trust between two companies, where authenticated users from one company can be trusted and considered authenticated by another company without the second company having to maintain the authentication information (username and password, typically). The various WS-* specifications have implementations from all the major vendors, and Microsoft is integrating the ideas into Active Directory through Active Directory Federation Services (ADFS).
In the realm of federated security, the WS-* arena certainly has more standards than the RESTful arena (and this will probably always continue to be the case), but there are efforts to support federated security in the world of REST. OpenID is one such effort. The .NET Service Bus (part of Windows Azure) also contains a federated identity service, which works just as well with HTTP (and therefore REST) as it does with SOAP-based services.

What about transactions?
Here is another area in which SOAP and WS-* have explicit support for an "advanced" feature and REST has none. WS-Atomic Transactions supports distributed, two-phase commit transactional semantics over SOAP-based services. REST has no support for distributed transactions.
Generally speaking, if you want something like transactions in a RESTful system, you create a new resource. (Creating a new resource whenever you run into a problem with a RESTful system generally solves most problems.) You can have a resource called Transaction. When your client needs to do something transactional (such as transferring money between two bank accounts), the client creates a Transaction resource that specifies all the correct resources affected (in my example, the two bank accounts) by doing a POST to the Transaction factory URI. The client can then perform updates by sending a PUT to the transaction URI and close the transaction by sending a DELETE to the URI.
This, of course, requires some amount of hand-coding and explicit control over your system, whereas the WS-Atomic Transactions system is more automatic because (in the case of Windows Communication Foundation) it is tied to your runtime's plumbing.
If your system absolutely needs atomic transactional semantics across diverse systems, WS-Atomic Transactions is probably the way to go. Using distributed transactions in this way may or may not be smart because it increases the coupling between the two systems and creates potential problems if you aren't controlling the code on both ends. But the most important thing is to use the right tool for the right job (once you've figure out what the right job is).
In defense of REST, I think it is fair to say that given today's distributed, service-oriented architectures, coupling two endpoints so tightly using a distributed transaction may not be the best design. On the other hand, some situations call for this type of functionality, and if you need it, use SOAP and WS-Atomic Transactions.

What about interoperability? Isn't SOAP supposed to be about interoperability? Isn't SOAP more interoperable than REST?
If you define interoperability as the technical ability to communicate between two divergent endpoints, I assert that REST wins the interoperability battle hands down.
Since one of the driving points behind creating the SOAP specification was to create an interoperable way to communicate between different platforms and different languages, many people are surprised by this assertion. But a funny thing happened on the way to widespread interoperability: the WS-* specifications (and vendors' implementations of said specifications) made SOAP services less interoperable rather than more interoperable.
The problem in the SOAP and WS-* arena is the large number of different standards (and versions of each of those standards) to choose from. And when a particular vendor chooses to implement a particular standard, that vendor often provides an implementation that is just slightly different from another vendor's (or all others). This leads to problems whenever you have to cross vendor boundaries (languages and operating system).
Of course, even to use SOAP you need a SOAP toolkit on your platform, which most (but not all) platforms have today. And then you have to deal with myriad WS-* specifications and figure out which to use (or not to use) and how that affects interoperability. To be honest, it's kind of a mess out there.
In terms of platforms, REST has the advantage because all you need to use REST is an HTTP stack (either on the client or the server). Since almost every platform and device has that today, I would argue that REST has the widest interoperability. Given that mobile devices, household devices, POS devices, DVD players, and TVs all have Internet connectivity, there are more and more platforms for which having a full SOAP toolkit is impossible or unlikely. And even if you do have a SOAP toolkit for a particular platform, the chance of it working with another platform's implementation is not 100%.

But what about metadata? So what if REST is so interoperable—there's no WSDL with REST, and without WSDL, I can't generate a client-side proxy to call a service. REST is hard to use.
It's true that in the world of REST, there is no direct support for generating a client from server-side-generated metadata, as there is in the world of SOAP with Web Service Description Language (WSDL). A couple of efforts are being made to get such support into REST, one being a parallel specification, known as WADL (Web Application Description Language). The other is a push to use WSDL 2.0 to describe RESTful endpoints. I often say that REST is simple, but simple doesn't always mean easy. SOAP is easy (because of WSDL), but easy doesn't always mean simple.
Yes, using WSDL makes generating a proxy for a SOAP-based service easier than writing the code to call a RESTful service. But once you generate that proxy, you still have to learn the API. Nothing in the WSDL tells you which method to call first or second or whether you need to call the methods in any particular order at all. These are all things you need to figure out after you generate the proxy and are prototyping the code to use the service.
Building a client against a RESTful service means you are learning the service and how it works as you build the client. Once you have finished, you have a complete understanding of the service, its resources, and the interaction you can have with those resources. To me, this is a big benefit. Since RESTful services follow the constraints of REST (at least they are supposed to), there is a convention that you can easily follow as you determine the different parts of the service.
Also, out in the wilds of developer-land, most services are wrapped in something often called a "service agent," which is another layer of indirection to protect clients from changes in the service layer. This may be needed in either REST or SOAP.
Another point is that metadata-generated proxies are part of what SOAP was meant to get away from in the RPC era, namely local-remote transparency. The concept of having an API on the client that matches the API on the server was considered to be a bad idea, but that's exactly what happens in most SOAP-based services. Having a metadata-generated proxy in REST also reduces the chances of taking advantage of hyperlinking. Using hypertext as the engine of application state (HATEOAS) is one of the constraints of REST, and using it requires a more loosely coupled client API.
The last point I'll make is that as support for REST becomes more ubiquitous, building clients will get easier and easier. If you look at the Windows Communication Foundation (WCF) REST starter kit, it includes facilities that head in this direction. The new HttpClient API makes using HTTP much easier than using the .NET WebRequest/WebResponse API. Also, there is a new Paste as XML Serializable tool, which allows you to copy a piece of XML (say from the documentation of a RESTful endpoint) and generate a .NET type that can represent that XML instance in your application. This is similar to what the WCF tools do automatically for the whole service with WSDL. Over time, these tools will become much more sophisticated, further simplifying the client experience in WCF when using RESTful services.

What if I want to use a transport other than HTTP?
The common (somewhat sarcastic) answer from the REST community here is, "Go ahead, there isn't anything stopping you." Realistically, however, REST is currently tied to HTTP, if only because most developers and teams of developers do not have the time for the engineering effort necessary to get the semantics of REST to work over, say, TCP/IP.
The common answer is technically correct, because nothing is stopping you from implementing the concepts of REST over other protocols, but until vendors add support for this, I find it a dubious proposition for most.

After all that information, aren't you telling me that REST is good for Internet-facing applications, and SOAP for enterprise applications?
If you've read the rest of this column, you can probably imagine that I think this statement is generalized and false. Often I hear this sentiment after discussing the lack of explicit distributed transaction support in REST versus the explicit support in WS-Atomic Transactions. My retort is generally something like "Well, ASP.NET doesn't have support for distributed transactions, but does that mean ASP.NET isn't useful for enterprises?"
My point is that not every technology solves every problem, and there are plenty of technologies that don't support the typical features people think of when they think of enterprises but that are incredibly helpful for enterprises nonetheless.
In fact, when I think of enterprise applications, I often think of speed and scalability—scalability being one of the main differences between REST and SOAP. SOAP services are much harder to scale than RESTful services, which is, of course, one of the reasons that REST is often chosen as the architecture for services that are exposed via the Internet (like Facebook, MySpace, Twitter, and so on).
Inside enterprises, applications also often need to scale as well. Using REST means that you can take advantage of HTTP caching and other features, like Conditional GET, that aid in scaling services. Many of these techniques can't be used with SOAP because SOAP uses POST only over HTTP.

Bottom Line
I hope that after you read this column, you'll think that the answer to "Which is better, REST or SOAP?" is "It depends." Both the REST architectural style and SOAP and the WS-* protocols have advantages and disadvantages when it comes to building services. Those of us in the RESTafarian camp (yes, I must give full disclosure here: I am definitely in that camp) believe that for most service situations, REST provides more benefits than SOAP or WS-*. On the other hand, SOAP and WS-* have some features that are easy (and possible) to implement using REST. When you need those specific features, you definitely want to use runtimes and toolkits that can provide those features. Although this column wasn't specifically about WCF, one nice feature of adopting WCF is that it supports both REST and SOAP/WS-*. Moving back and forth between the two worlds becomes easier if you have one programming and runtime model to learn.

Send your questions and comments to sstation@microsoft.com.

Jon Flanders is an independent consultant, speaker, and trainer for Pluralsight. He specializes in BizTalk Server, Windows Workflow Foundation, and Windows Communication Foundation. You can contact Jon at masteringbiztalk.com/blogs/jon.

Service Station
Weitere Informationen zu REST
Jon Flanders
In den letzten beiden Spalten habe ich beschrieben die Grundlagen der REST und zum Verfügbarmachen und verbraucht Web Feeds erläutert. In dieser Spalte werde ich eine Reihe von Fragen beantworten, die häufig ausdenken, beim Erstellen von Präsentationen oder Durchführen von Schulungen zur Verwendung von REST zum Dienst-basierte Anwendungen erstellen.

Was ist besser, REST oder SOAP?
Dies ist eine der häufigsten Fragen zu REST erhalte, und es ist wahrscheinlich die am wenigsten gerecht. REST und SOAP sind häufig "Web Services," bezeichnet werdenund eine wird häufig verwendet anstelle des anderen, jedoch völlig unterschiedliche Ansätze sind. REST ist ein Architekturstil zum Erstellen von Client / Server-Anwendungen. SOAP ist eine Protokollspezifikation für den Datenaustausch zwischen zwei Endpunkten.
Vergleichen von REST mit dem remote Procedure Call (RPC)-Stil des Client / Server-Anwendungen erstellen werden genauer. RPC ist eine Formatvorlage (anstelle eines Protokolls, ist SOAP) Erstellen von Client / Server-Anwendungen in der ein Proxy (im Allgemeinen aus Metadaten generiert) wird im Adressbereich des Clients verwendet, um mit dem Server zu kommunizieren und die Proxyschnittstelle imitiert Schnittstelle des Servers. Obwohl SOAP-RPC-Format nicht erforderlich ist, werden die meisten modernen SOAP-Toolkits in Richtung ausgerichtet (mindestens diese Standardeinstellung um) mithilfe von RPC.
Im Gegensatz zu RPC, REST verfügt nicht über den Proxy Metadaten generiert (Siehe die nächste Frage Informationen), d. h., die der Client weniger auf den Dienst gekoppelt. Da REST auf die Semantik des HTTP-basiert, können auch Anforderungen für Daten (GET-Anforderungen) zwischengespeichert. RPC-Systeme verfügen im Allgemeinen keine solche Infrastruktur (und sogar bei RPC mit SOAP über HTTP, können nicht SOAP-Antworten zwischengespeichert, da SOAP das Verb HTTP POST verwendet, das als unsicher betrachtet wird). SOAP-eschews absichtlich HTTP, insbesondere damit SOAP, über andere Protokolle zu arbeiten, so dass Sie tatsächlich etwas disingenuous SOAP-basierte Dienste Webdienste aufrufen.
Meiner Sicht ist, dass REST und SOAP verwendet werden, können um ähnliche Funktionalität implementieren, aber im Allgemeinen SOAP verwendet, wenn ein bestimmtes Feature von SOAP erforderlich ist und die Vorteile von REST Sie in der Regel die beste Option andernfalls können.

Was ist mit Sicherheit? Nicht SOAP-mehr Sicherheit als REST?
Diese Frage berührt eine eigene Haustier Peeves ist die Antwort offensichtlich keine. Es ist nur als einfach ein REST-Diensts sichere vornehmen, wie er einen SOAP-basierten Dienst sicher. In den meisten Fällen REST oder SOAP ist das Sicherheitssystem identisch: eine Art von HTTP-basierte Authentifizierung und SSL (Secure Sockets Layer). Zwar technisch die Technologie für sichere Konversationen über HTTP jetzt TLS (Transport Layer Security) aufgerufen wird, ist SSL immer noch der Name am häufigsten verwendet.
Was true ist, dass ein SOAP-basierten Dienst, aufgrund der zusätzlichen Protokolle in verschiedenen WS-angegeben * Spezifikationen, ist Unterstützung End-to-End-Nachrichtensicherheit. Dies bedeutet, dass wenn Sie SOAP-Nachrichten von Endpunkt zu Endpunkt zu Endpunkt, über die Protokolle dieselben oder unterschiedliche übergeben die Nachricht sicheren ist. Wenn Ihre Anwendung diese bestimmte Funktion, SOAP und WS-* ist definitiv die Möglichkeit, zu wechseln. REST wahrscheinlich wäre eine Option hier wegen ihrer Abhängigkeit von HTTP nicht und grundsätzlich Sie würden werden Entwerfen einer Multiprotokoll-Anwendung. Ich glaube, dass die Tatsache, die mit WS-SOAP * ermöglicht End-to-End Nachrichtenebenensicherheit ist die Quelle der Missverständnis, dass SOAP-basierte Dienste sicherer als Rest-Dienste sind.
Einen anderen Bereich in dem der WS-* Leute haben viel Zeit damit verbracht und Aufwand ist vor kurzem Verbundsicherheit. Einfache Idee Verbundidentität wird Vertrauensstellung zwischen zwei Unternehmen, erstellt, wobei authentifizierte Benutzer von einem Unternehmen vertrauenswürdige und betrachtet werden können von einem anderen Unternehmen ohne das zweite Unternehmen muss die Authentifizierungsinformationen authentifiziert (Benutzername und Kennwort in der Regel). Verschiedene WS-* Spezifikationen sind die wichtigsten Kreditoren-Implementierungen und Microsoft ist die Ideen in Active Directory über Active Directory Federation Services (ADFS) integrieren.
In den Bereich der Verbundsicherheit, WS-* Bereich hat sicherlich weitere Standards als Rest Bereich (und dies wird wahrscheinlich immer weiterhin der Fall sein), aber es Bemühungen gibt um Verbundsicherheit in die Welt der REST zu unterstützen. OpenID ist eine solche Aufwand. Der .NET Service Bus (Bestandteil von Windows Azure) enthält auch einen Verbundidentität-Dienst, welche funktioniert mit HTTP (und daher REST) als es mit SOAP-basierte Dienste ebenso einfach ist.

Was ist mit Transaktionen?
Hier ist ein weiterer Bereich in der SOAP und WS-* bieten explizite Unterstützung für einen "erweiterten"Funktion und der REST hat keine. WS-atomaren Transaktionen unterstützt verteilte, Zweiphasen-Commit-Transaktionssemantik über SOAP-basierte Dienste. REST bietet keine Unterstützung für verteilte Transaktionen.
Wenn Sie etwa Transaktionen in einem Rest System möchten, erstellen Sie im Allgemeinen eine neue Ressource. (Eine neue Ressource erstellen, wenn Sie ein Problem mit einem Rest System, i. d. r. ausführen die meisten Probleme behoben.) Sie können eine Ressource Transaktion aufgerufen haben. Wenn der Client muss etwas Transaktionsnachrichten (z. B. Geld zwischen zwei Bankkonten übertragen), erstellt der Client eine Transaktion-Ressource, die alle erforderlichen Ressourcen betroffen (in meinem Beispiel zwei Bankkonten) auf diese Weise einer POST an der Transaktion Factory URI angibt. Der Client kann dann Aktualisierungen durch Senden einer PUT an der Transaktion URI durchführen und schließen Sie die Transaktion durch Senden einer DELETE an den URI.
Natürlich erfordert, einige Menge Hand Codieren und explizite Kontrolle über Ihr System, während das System WS atomaren Transaktionen mehr automatische ist, da (im Fall von Windows Communication Foundation), die Common Language Runtime Sanitär-gebunden ist.
Wenn Ihr System über verschiedene Systeme hinweg absolut atomaren Transaktionssemantik benötigt, ist WS atomaren Transaktionen wahrscheinlich die Möglichkeit zu wechseln. Mithilfe von verteilte Transaktionen auf diese Weise kann oder nicht smart da die Kopplung zwischen den beiden Systemen erhöht und potenzielle Probleme erstellt, wenn Sie den Code an beiden Enden steuern werden nicht. Aber am wichtigsten ist das Verwenden des richtigen Tools für die richtige Auftrag, (sobald Sie heraus, welche Rechte Auftrag ermitteln haben).
Verteidigung von REST denke ich es Messe zu sagen, dass bestimmte heutigen verteilt, serviceorientierte Architekturen, zwei Endpunkten Kopplung eng mithilfe einer verteilten Transaktion den optimalen Entwurf möglicherweise nicht ist. Andererseits, Situationen rufen Sie für diese Art von Funktionalität, und wenn Sie es verwenden, SOAP und WS-atomaren Transaktionen.

Was ist Interoperabilität? Sollen ist nicht SOAP über die Interoperabilität werden? Nicht SOAP-Interoperabilität als REST?
Wenn Sie die technische Möglichkeit, die Kommunikation zwischen zwei Endpunkten Divergente Interoperabilität definieren, assert ich, dass REST die Interoperabilität kämpfen hands unten wins.
Seit einen der treibenden Punkte hinter die SOAP-Spezifikation erstellen eine interoperable Möglichkeit zur Kommunikation zwischen verschiedenen Plattformen und andere Sprachen erstellen, werden viele Personen durch diese Assertion überrascht. Aber ein lustiges auf dem Weg zu weit verbreiteten Interoperabilität: Die WS-* Spezifikationen (und KreditorenImplementierungen der besagte Spezifikationen) vorgenommen SOAP-Dienste mehr interoperable statt weniger Interoperabilität.
Das Problem in SOAP und WS-* Bereich ist, große Anzahl unterschiedlicher Standards (und Versionen dieser Standards) aus. Und wenn ein bestimmter Kreditor ein bestimmtes Standard-implementieren möchte, häufig bietet eine Implementierung, die sich nur geringfügig von anderen unterscheidet, Kreditor des Kreditors (oder alle anderen). Dies führt zu Problemen, wenn cross-Kreditor-Grenzen (Sprachen und Betriebssystem).
Natürlich müssen auch SOAP verwenden Sie eine SOAP-Toolkit auf Ihrer Plattform die meisten (aber nicht alle) Plattformen heute haben. Und zum Umgang mit unzähligen WS-* Spezifikationen und Abbildung, welche verwenden (oder nicht zu verwenden), die Auswirkungen der Interoperabilität. Um ehrlich zu sein, ist es Art von ein Chaos draußen.
REST hat hinsichtlich der Plattformen den Vorteil, da müssen Sie den REST Verwenden eines HTTP-Protokollstapel (entweder auf dem Client oder Server) ist. Da fast jeder Plattform und Gerät, die heute hat, würde ich argumentieren, dass REST die breiteste Interoperabilität hat. Angegebenen, mobile Geräte, Haushalt Geräte, POS-Geräte, DVD-Playern und Fernseher alle Internet-Konnektivität verfügen, gibt es mehr und mehr Plattformen, für welche, die müssen einen vollständigen SOAP-Toolkit unmöglich oder unwahrscheinlich ist. Und selbst wenn Sie eine SOAP-Toolkit für eine bestimmte Plattform verfügen, die Wahrscheinlichkeit es die Arbeit mit einer anderen Plattform Implementierung ist nicht 100 %.

Aber was Metadaten? Was geschieht, wenn REST also so interoperable – es gibt keine WSDL mit REST und ohne WSDL, ich kann nicht generiert einen clientseitigen Proxy einen Dienst aufrufen. REST ist schwierig, verwenden.
Es ist WAHR, dass in der Welt von REST, es keine direkte Unterstützung für Generieren von einen Client aus Server-Seite generiert Metadaten ist wie in der Welt der SOAP mit WSDL (Web Service Description Language). Eine Reihe von Maßnahmen werden vorgenommen wird, um solche Supportinformationen in REST, eine eine parallele Spezifikation als WADL (Web Application Description Language) bezeichnet wird. Der andere ist ein Push mit WSDL 2.0 um Rest-Endpunkten zu beschreiben. Ich sage häufig, dass REST einfach ist, jedoch einfach nicht immer einfach bedeutet. SOAP ist einfach (aufgrund der WSDL), aber einfach immer bedeutet nicht einfach.
Ja, wird mithilfe von WSDL einen Proxy für einen SOAP-basierten Dienst einfacher als das Schreiben von Code zum Aufrufen eines REST-Diensts generiert. Aber sobald Sie diesen Proxy generieren, Sie weiterhin um die API erfahren. Nichts in der WSDL teilt Ihnen mit die Methode, um ersten oder zweiten Aufruf oder, ob Sie überhaupt die Methoden in einer bestimmten Reihenfolge aufrufen müssen. Dies sind alle Dinge, die Sie müssen herausfinden, nachdem Sie den Proxy zu generieren und Prototypen der Code, den Dienst zu verwenden sind.
Erstellen einen Client anhand eines REST-Diensts bedeutet, dass Sie Lernressourcen sind, den Dienst und wie es funktioniert, wie Sie den Client erstellen. Sobald Sie abgeschlossen haben, haben Sie ein vollständiges Verständnis der Dienst, dessen Ressourcen und die Interaktion, die Sie mit diesen Ressourcen verfügen können. Für mich ist dies ein großer Vorteil. Da Rest-Dienste führen Sie die Einschränkungen von REST (mindestens diese sollen), ist eine Konvention, die Sie leicht folgen können, wie Sie die verschiedenen Teile des Dienstes ermitteln.
Darüber hinaus sind out in Wilds der Entwickler-Land, die meisten Dienste in etwas häufig bezeichnet einen „ Dienst-Agenten,"eingeschlosseneine weitere Schicht der Dereferenzierung zum Schutz von Clients von Änderungen in der Dienstschicht ist. Dies kann in REST oder SOAP-benötigt.
Ein weiterer Punkt ist, dass Metadaten generierte Proxys Teil Was soll SOAP im RPC-Zeitraum, nämlich Local Remote Transparenz verlassen wurde. Wurde das Konzept der müssen einer API auf dem Client, der die API auf dem Server entspricht betrachtet eine schlechte Idee, aber das ist genau was in den meisten SOAP-basierte Dienste geschieht. Über einen Proxy Metadaten generiert in REST verringert außerdem die Chancen Hyperlinking nutzen. Mithilfe von Hypertext als das Datenbankmodul des Anwendungszustands (HATEOAS) ist eine der Einschränkungen von REST und verwenden es erfordert eine lose Client-API.
Der letzte Punkt ich werde, ist, dass als Unterstützung für REST mehr weit verbreitete wird Clients Erstellen einfacher erhalten und einfacher. Wenn Sie die Windows Communication Foundation (WCF) REST Starter Kit betrachten, enthält Funktionen, Head in diese Richtung. Mithilfe von HTTP viel einfacher als mit der .NET WebRequest/WebResponse-API neue HttpClient-API-erleichtert. Ist auch eine neue einfügen als Serializable XML-Tool, wodurch Sie einen Teil der XML (beispielsweise aus der Dokumentation einen REST-Endpunkt) kopieren und generiert einen .NET Typ, der die XML-Instanz in der Anwendung darstellen kann. Dies ähnelt dem Vorgehen WCF-Tools automatisch für den gesamten Dienst mit WSDL. Im Laufe der Zeit werden diese Tools viel komplexere, die Clienterfahrung in WCF weiter zu vereinfachen, wenn Rest-Dienste verwenden.

Was geschieht, wenn ich möchte einen Transport an andere als HTTP verwenden?
Die allgemeine (etwas Sarkastisches) Antwort aus der REST-Community ist, "Gehe im voraus, etwas beenden Sie es nicht." Realistisch, jedoch REST ist zurzeit an gebunden HTTP, wenn nur, da die meisten Entwickler und Teams von Entwicklern nicht die Zeit für den engineering Aufwand erforderlich, die Semantik von REST erhalten, arbeiten verfügen z. B. TCP/IP.
Die häufige Antwort ist technisch korrekt, da nichts ist verhindern Sie die Konzepte von REST über andere Protokolle implementieren, aber bis Hersteller die Unterstützung für diese hinzufügen, es eine zweifelhafte Angelegenheit für die meisten finde.

Nachdem alle diese Informationen mitteilt sind nicht mir, dass REST gut für Anwendungen mit Internetverbindung und SOAP für Enterprise-Anwendungen ist?
Wenn Sie den Rest dieses Artikels gelesen haben, können Sie wahrscheinlich vorstellen, dass ich denke diese Anweisung verallgemeinerte und false ist. Häufig hören Sie diese Gefühlslage nach erörtern den Mangel an explizite verteilte Transaktionsunterstützung in REST gegenüber explizite Unterstützung in WS-atomaren Transaktionen. Meine Retort ist im Allgemeinen etwa "nun, XML-Webdienste Unterstützung für verteilte Transaktionen, jedoch unterstützt, die bedeuten keinen XML-Webdienste ist nicht für Unternehmen nützlich?"
Meine Punkt ist, dass nicht jeder Technologie jedes Problem löst und vorhanden sind, sind trotzdem unglaublich nützlich für Unternehmen jedoch viel Technologien, die die Personen typischen Features nicht unterstützen diese Unternehmen denken vorstellen.
Wenn ich von Unternehmensanwendungen denken, ich glaube sogar häufig dass Geschwindigkeit und Skalierbarkeit – Skalierbarkeit wird eines der wichtigsten Unterschiede zwischen REST und SOAP. SOAP-Dienste sind viel schwerer zu skalieren als Rest-Dienste, die natürlich ist einer der Gründe, die REST häufig als die Architektur für Dienste ausgewählt ist, die über das Internet (wie Facebook, MySpace, Twitter und usw.) verfügbar gemacht werden.
In Unternehmen müssen Anwendungen häufig auch als gut skalieren. Verwendung von REST bedeutet, dass Sie Vorteil von HTTP-Zwischenspeicherung und andere Features, wie bedingte GET, die Skalierung Dienste unterstützen nutzen können. Viele dieser Techniken können nicht mit SOAP verwendet werden, da SOAP nur über HTTP POST verwendet.

Endergebnis
Ich hoffe, nachdem Sie diese Spalte gelesen, Meinung wird die Antwort "der ist besser, REST oder SOAP-?"ist "Es hängt." Sowohl der REST-Architekturstil und SOAP und die WS-* Protokolle haben vor- und Nachteile beim Erstellen von Diensten. Jene von uns in RESTafarian Ferienlager (Ja, muss ich hier vollständige Offenlegung erteilen: Ich bin definitiv in die Ferienlager) glauben, dass für die meisten Service-Situationen REST mehr Vorteile als SOAP- oder WS-bietet *. Auf der Hand SOAP und WS-* verfügen über einige Features, die einfach (und mögliche) sind, Verwendung von REST zu implementieren. Wenn Sie diese spezifischen Features benötigen, möchten Sie definitiv verwenden, Laufzeiten und Toolkits, die diese Features bereitstellen kann. Obwohl war nicht in dieser Spalte insbesondere über WCF ein nützliches Feature der Übernahme von WCF ist dass REST und SOAP-WS unterstützt-*. Hin und her Verschieben zwischen beiden Welten wird vereinfacht, wenn Sie eine Programmierung und Laufzeitmodell erhalten haben.

Senden Sie Ihre Fragen und Kommentare zu sstation@microsoft.com.

Jon Flanders ist unabhängiger Berater, Referent und Trainer für Pluralsight. Er spezialisiert sich auf in BizTalk Server, Windows Workflow Foundation und Windows Communication Foundation. Sie können Jon unter masteringbiztalk.com/blogs/jon Kontakt.

 

Current Issue

 

 

 

Tip: Click the printer button in your browser toolbar to get the printer friendly version of this article.

 

Page view tracker