jueves, 23 de marzo de 2017

SOAP vs REST Web Services

REST vs SOAP Web Services
I am seeing a lot of new web services are implemented using a REST style architecture these days rather than a SOAP one. Lets step back a second and explain what REST is.
What is a REST Web Service
The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in practice most of the services use a POST for this).
Who's using REST?
All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.
Who's using SOAP?
Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.
REST vs SOAP
As you may have noticed the companies I mentioned that are using REST api's haven't been around for very long, and their apis came out this year mostly. So REST is definitely the trendy way to create a web service, if creating web services could ever be trendy (lets face it you use soap to wash, and you rest when your tired). The main advantages of REST web services are:
Lightweight - not a lot of extra xml markup Human Readable Results Easy to build - no toolkits required SOAP also has some advantages:
Easy to consume - sometimes Rigid - type checking, adheres to a contract Development tools For consuming web services, its sometimes a toss up between which is easier. For instance Google's AdWords web service is really hard to consume (in CF anyways), it uses SOAP headers, and a number of other things that make it kind of difficult. On the converse, Amazon's REST web service can sometimes be tricky to parse because it can be highly nested, and the result schema can vary quite a bit based on what you search for.
Which ever architecture you choose make sure its easy for developers to access it, and well documented.



218
down voteaccepted
REST is almost always going to be faster. The main advantage of SOAP is that it provides a mechanism for services to describe themselves to clients, and to advertise their existence.
REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve. However, the clients have to know what to send and what to expect.
In general, When you're publishing an API to the outside world that is either complex or likely to change, SOAP will be more useful. Other than that, REST is usually the better option.
up vote56down vote
REST vs SOAP Web Services
I am seeing a lot of new web services are implemented using a REST style architecture these days rather than a SOAP one. Lets step back a second and explain what REST is.
What is a REST Web Service
The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in practice most of the services use a POST for this).
Who's using REST?
All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.
Who's using SOAP?
Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.
REST vs SOAP
As you may have noticed the companies I mentioned that are using REST api's haven't been around for very long, and their apis came out this year mostly. So REST is definitely the trendy way to create a web service, if creating web services could ever be trendy (lets face it you use soap to wash, and you rest when your tired). The main advantages of REST web services are:
Lightweight - not a lot of extra xml markup Human Readable Results Easy to build - no toolkits required SOAP also has some advantages:
Easy to consume - sometimes Rigid - type checking, adheres to a contract Development tools For consuming web services, its sometimes a toss up between which is easier. For instance Google's AdWords web service is really hard to consume (in CF anyways), it uses SOAP headers, and a number of other things that make it kind of difficult. On the converse, Amazon's REST web service can sometimes be tricky to parse because it can be highly nested, and the result schema can vary quite a bit based on what you search for.
Which ever architecture you choose make sure its easy for developers to access it, and well documented.
Understanding SOAP and REST Basics And Differences
January 8, 2013 by John Mueller 98 Comments
Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) are two answers to the same question: how to access Web services. The choice initially may seem easy, but at times it can be surprisingly difficult.
SOAP is a standards-based Web services access protocol that has been around for a while and enjoys all of the benefits of long-term use. Originally developed by Microsoft, SOAP really isn’t as simple as the acronym would suggest.
The Difference between SOAP vs REST APIs
REST is the newcomer to the block. It seeks to fix the problems with SOAP and provide a truly simple method of accessing Web services. However, sometimes SOAP is actually easier to use; sometimes REST has problems of its own. Both techniques have issues to consider when deciding which protocol to use.
Before I go any further, it’s important to clarify that while both SOAP and REST share similarities over the HTTP protocol, SOAP is a more rigid set of messaging patterns than REST. The rules in SOAP are important because without these rules, you can’t achieve any level of standardization. REST as an architecture style does not require processing and is naturally more flexible. Both SOAP and REST rely on well-established rules that everyone has agreed to abide by in the interest of exchanging information.
A Quick Overview of SOAP
SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet such as the Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). These technologies fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet.
After an initial release, Microsoft submitted SOAP to the Internet Engineering Task Force (IETF) where it was standardized. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets. In fact, you can find a whole laundry list of these standards on Web Services Standards.
The point is that SOAP is highly extensible, but you only use the pieces you need for a particular task. For example, when using a public Web service that’s freely available to everyone, you really don’t have much need for WS-Security.
The XML used to make requests and receive responses in SOAP can become extremely complex. In some programming languages, you need to build those requests manually, which becomes problematic because SOAP is intolerant of errors. However, other languages can use shortcuts that SOAP provides; that can help you reduce the effort required to create the request and to parse the response. In fact, when working with .NET languages, you never even see the XML.
Part of the magic is the Web Services Description Language (WSDL). This is another file that’s associated with SOAP. It provides a definition of how the Web service works, so that when you create a reference to it, the IDE can completely automate the process. So, the difficulty of using SOAP depends to a large degree on the language you use.
One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. Given that you might not own the Web service, this particular feature is extremely important; otherwise you would be left guessing as to why things didn’t work. The error reporting even provides standardized codes so that it’s possible to automate some error handling tasks in your code.
An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you can’t use it over other transports. In fact, developers in some languages, such as Python and PHP, are doing just that.
A Quick Overview of REST
Many developers found SOAP cumbersome and hard to use. For example, working with SOAP in JavaScript means writing a ton of code to perform extremely simple tasks because you must create the required XML structure absolutely every time.
REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations you must provide additional information in special ways, but most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.
Unlike SOAP, REST doesn’t have to use XML to provide the response. You can find REST-based Web services that output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can obtain the output you need in a form that’s easy to parse within the language you need for your application.
As an example of working with REST, you could create a URL for Weather Underground. The API’s documentation page shows an example URL of http://api.wunderground.com/api/Your_Key/conditions/q/CA/San_Francisco.json. The information you receive in return is a JSON formatted document containing the weather for San Francisco. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application.
Deciding Between SOAP and REST
Before you spend hours fretting over the choice between SOAP and REST, consider that some Web services support one and some the other. Unless you plan to create your own Web service, the decision of which protocol to use may already be made for you. Extremely few Web services, such as Amazon, support both. The focus of your decision often centers on which Web service best meets your needs, rather than which protocol to use.
Soap Vs Rest
SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:
§  Language, platform, and transport independent (REST requires use of HTTP)
§  Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
§  Standardized
§  Provides significant pre-build extensibility in the form of the WS* standards
§  Built-in error handling
§  Automation when used with certain language products
REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:
§  No expensive tools require to interact with the Web service
§  Smaller learning curve
§  Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
§  Fast (no extensive processing required)
§  Closer to other Web technologies in design philosophy
Locating Free Web Services
The best way to discover whether SOAP or REST works best for you is to try a number of free Web services. Rolling your own Web service can be a painful process, so it’s much better to make use of someone else’s hard work. In addition, as you work with these free Web services you may discover that they fulfill a need in your organization, and you can save your organization both time and money by using them. Here are some to check out:
§  XMethods
One common concern about using a free Web service is the perception that it could somehow damage your system or network. Web services typically send you text, not scripts, code, or binary data, so the risks are actually quite small.
Of course, there’s also the concern that Web services will disappear overnight. In most cases, these Web services are exceptionally stable and it’s unlikely that any of them will disappear anytime soon. I’ve been using some of them now for five years without any problem. However, stick with Web services from organizations with a large Internet presence. Research the Web service before you begin using it.
Working with the Geocoder Web Service
To make it easier to understand how SOAP and REST compare, I decided to provide examples of both using the same free Web service, geocoder.us (thank you to Mark Yuabov for suggesting it). This simple Web service accepts an address as input and spits out a longitude and latitude as output. You could probably mix it with the Google Maps API example I present in “Using the Google Maps API to Add Cool Stuff to Your Applications.”
Viewing a Simple REST Example
Sometimes, simple is best. In this case, REST is about as simple as it gets because all you need is an URL. Open your browser—it doesn’t matter which one—and type http://rpc.geocoder.us/service/csv?address=1600+Pennsylvania+Ave,+Washington+DC in the address field. Press Enter. You’ll see the output in your browser in CSV format:
GeoCoder REST example
You see the latitude, followed by the longitude, followed by the address you provided. This simple test works for most addresses in most major cities (it doesn’t work too well for rural addresses, but hey, what do you expect for free?). The idea is that you obtain the latitude and longitude needed for use with other Web services. By combining Web services together with a little glue code, you can create really interesting applications that do amazing things in an incredibly short time with little effort on your part. Everyone else is doing the heavy lifting. You can also test your REST API with simple to use tools like SoapUI.
Explaining a Simple SOAP Example
SOAP, by its very nature, requires a little more setup, but I think you’ll be amazed at how simple it is to use.
Begin this example by creating Windows Forms application using Visual Studio. The sample code uses C#, but the same technique works fine with other .NET languages (you’ll need to modify the code to fit). Add labels, textboxes, and buttons as shown here (the Latitude and Longitude fields are read-only).
GeoCoder SOAP example
Here’s where the automation comes into play. Right click References in Solution Explorer and choose Add Service Reference from the context menu. You’ll see the Add Service Reference dialog box. Type the following address into the address field: http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl and click Go. Type GeocoderService in the namespace field. Your dialog box should look like the one shown here.
GeoCoder Web service
Click OK. Visual Studio adds the code needed to work with Geocoder in the background.
At this point, you’re ready to use the Web service. All you need to do is to add some code to the Get Position button as shown here.
private void btnGetPosition_Click(object sender, EventArgs e)
{
   // Create the client.
   GeocoderService.GeoCode_PortTypeClient Client =
      new GeocoderService.GeoCode_PortTypeClient();
   // Make the call.
   GeocoderService.GeocoderResult[] Result =
      Client.geocode(txtAddress.Text);
   // Check for an error result.
   if (Result != null)
   {
      // Display the results on screen.
      txtLatitude.Text = Result[0].lat.ToString();
      txtLongitude.Text = Result[0].@long.ToString();
   }
   else
   {
      // Display an error result.
      txtLatitude.Text = "Error";
      txtLongitude.Text = "Error";
   }
}
The code begins by creating a client. This is a common step for any Web service you use with Visual Studio (or other environments that support SOAP natively). To see another version of the same step, check out the PHP example.
After you create the client, you use it to call one of the methods supported by the Web service. In this case, you call geocode() and pass the address you want to work with. The result of the call is stored in a GeocoderResult variable named Result. A single address could possibly end up providing multiple positions if you aren’t specific enough, so this information is passed back as an array.
Let’s assume that no errors occur (resulting in a null return value). The example assumes that you provided great information, so it places the information found in the first Result entry into the Latitude and Longitude output. So, this example isn’t really that complicated compared with REST, but as you can see, even a simple example is more work.
The Bottom Line: When To Use SOAP Or REST
Some people try to say that one process is better than the other, but this statement is incorrect. Each protocol has definite advantages and equally problematic disadvantages. You need to select between SOAP and REST based on the programming language you use, the environment in which you use it, and the requirements of the application. Sometimes SOAP is a better choice and other times REST is a better choice. In order to avoid problems later, you really do need to chart the advantages and disadvantages of a particular solution in your specific situation.
There’s one absolute you should get from this article. Don’t reinvent the wheel. It’s amazing to see companies spend big bucks to create Web services that already exist (and do a better job than the Web service the company creates). Look for free alternatives whenever possible. In many cases, the choice of Web service also determines your choice of protocol.
Actually there are two. Whether you pick between SOAP or REST for your web service, making sure you thoroughly test your APIs. Ready! API has a full suite of functional, performance, security and virtualization tools for your API testing needs. You can also learn how to test RESTful APIs, in our API Testing Resource Center.

SOAP vs REST Web Services


domingo, 12 de marzo de 2017

EL CIENTÍFICO REBELDE

EL CIENTÍFICO REBELDE

Si la ciencia dejara de rebelarse contra la autoridad, no merecería los talentos de nuestros niños más brillantes.

Freeman Dyson

1 Cuando el científico es un rebelde No existe en absoluto una única visión científica, del mismo modo que no hay una única visión poética. La ciencia es un mosaico de puntos de vista parciales y contradictorios. Sin embargo, hay un elemento común en esos puntos de vista: la rebelión contra las restricciones impuestas por la cultura dominante en el ámbito local, occidental u oriental, según el caso. La visión científica no es específicamente occidental. Al menos, no más que árabe, india, japonesa o china. Los árabes, indios, japoneses y chinos tienen una gran participación en el desarrollo de la ciencia moderna. Además, hace dos mil años, los comienzos de la ciencia antigua fueron tan babilonios y egipcios como griegos. Uno de los hechos centrales en cuanto a la ciencia es que esta no repara en lo que sea Oriente y Occidente, norte y sur, y negro, amarillo o blanco. Pertenece a todo aquel que esté dispuesto a hacer el esfuerzo de aprenderla. Y lo que es cierto en la ciencia, lo es también en la poesía. La poesía no la inventaron los occidentales. La India posee una poesía anterior a la de Homero. La poesía está tan inmersa en las culturas árabe y japonesa como lo está en la rusa y la inglesa. El hecho de que yo cite poemas en inglés no significa que la visión de la poesía tenga que ser occidental. La poesía y la ciencia son dones concedidos a toda la humanidad.

Para el gran matemático y astrónomo Omar Jayyam, la ciencia era una rebelión contra las restricciones intelectuales del islam, que se expresa de la manera más directa en sus incomparables versos: Y ese cuenco invertido que llamamos cielo, bajo el cual vivimos y morimos encerrados y arrastrándonos, no alces tus manos hacia él pidiendo ayuda, —porque él rueda tan impotente como tú o yo. Para las primeras generaciones de científicos japoneses del siglo xix, la ciencia era una rebelión contra su tradicional cultura de feudalismo. Para los grandes físicos indios de este siglo (Raman, Bose y Saha), la ciencia fue una doble rebelión: primero contra la dominación inglesa, y en segundo lugar contra la ética fatalista del hinduismo. Y también en Occidente, desde Galileo hasta Einstein, ha habido grandes científicos que han sido rebeldes. He aquí cómo describía la situación el propio Einstein: Cuando estaba en el séptimo grado en el Luitpold Gymnasium de Múnich, fui convocado por mi tutor, que me expresó el deseo de que yo abandonara el centro. Al decirle yo que no

había hecho nada malo, se limitó a contestar: «Su mera presencia hace que la clase me pierda el respeto». Einstein se alegró de poder ayudar al profesor. Siguió su consejo y abandonó el instituto a los quince años de edad. Con este ejemplo, y otros muchos, vemos que la ciencia no está gobernada por las reglas de la filosofía o la metodología occidentales. La ciencia es una alianza de los espíritus libres de todas las culturas, y se rebela contra la tiranía local que cada una de ellas impone a sus hijos. En la medida en que soy un científico, mi visión del universo no es reduccionista ni antirreduccionista. No sirvo para adscribirme a «ismos» occidentales de ninguna clase. Me siento un viajero que realiza el «viaje inmenso» del paleontólogo Loren Eiseley, un viaje que es mucho más largo que la historia de las naciones y las filosofías, más largo incluso que la historia de nuestra especie. Hace unos años, una exposición de arte rupestre del paleolítico llegó al Museo de Historia Natural de Nueva York. Era una oportunidad estupenda para ver en un mismo lugar las tallas en piedra y hueso que normalmente se exponen separadamente en una docena de museos franceses. En su mayoría, las tallas estaban hechas en Francia hace unos catorce mil años, durante un breve florecimiento de la creación artística al final de la última glaciación. La belleza y la delicadeza de las tallas eran extraordinarias. Las personas que tallaron esos objetos no pudieron ser unos vulgares cazadores que se entretenían alrededor del fuego en una cueva. Tuvieron que ser unos hábiles artistas inmersos en una cultura de alto nivel. Cuando se ven esos objetos por primera vez, la mayor sorpresa es el hecho de que su cultura no es occidental. No guardan parecido alguno con el arte primitivo que apareció diez mil años más tarde en Mesopotamia, Egipto y Creta. Si no hubiera sabido que aquel viejo arte rupestre tenía su origen en Francia, habría pensado que procedía de Japón. Su estilo parece hoy día más japonés que europeo. Aquella exposición mostraba vívidamente que en períodos de diez mil años las distinciones entre las culturas occidentales, orientales y africanas pierden todo su significado. Durante un intervalo de cien mil años somos todos africanos. Y durante un intervalo de trescientos millones de años somos todos unos anfibios que caminan vacilantes como patos, saliendo de unas charcas secas a una tierra extraña y hostil. A esta larga visión del pasado se une la visión aún más larga del futuro que propone Robinson Jeffers. En un período de tiempo suficientemente largo, no solo es transitoria la civilización europea, sino también la propia especie humana. He aquí la visión de Robinson Jeffers, expresada en distintos pasajes de su largo poema «El hacha de doble filo» («The Double Axe»): Venid, pequeños. No valéis más que los zorros y los lobos amarillos, pero os daré sabiduría.

Oh, niños futuros: vendrá el infortunio; el mundo del presente navega sobre sus rocas; pero naceréis y viviréis después. También llegará un día en que la Tierra se arañe a sí misma y, con una sonrisa, se quite de encima a la humanidad: pero naceréis antes de que eso suceda. Llegará, sin duda, un tiempo en que también el Sol morirá; los planetas se congelarán, al igual que el aire sobre ellos; gases helados, copos blancos de aire formarán el polvo: que ningún viento sacudirá: este mismo polvo que reluce como suave luz de estrellas es viento muerto, el cadáver blanco del viento. También la galaxia morirá; el brillo de la Vía Láctea, nuestro universo, todas las estrellas que tienen nombre están muertas. Vasta es la noche. ¡Cómo has crecido, querida noche, recorriendo tus salones vacíos, qué alta estás!1 Robinson Jeffers no era científico, pero expresó la visión científica mejor que ningún otro poeta. Irónico, independiente, desdeñando al igual que Einstein el orgullo patriótico y los tabúes culturales, solo tenía miedo a la naturaleza. Se quedó solo en su inflexible oposición a los disparates de la Segunda Guerra Mundial. Los poemas de frenesí patriótico que escribió durante aquellos años eran imposibles de publicar. «El hacha de doble filo» se publicó finalmente en 1948, después de una larga disputa entre Jeffers y sus editores. Descubrí a este poeta treinta años más tarde, cuando las penas y la cólera de la guerra se habían convertido en un recuerdo lejano. Afortunadamente sus obras se están publicando en la actualidad y pueden ustedes leerlas por sí mismos. La ciencia como actividad subversiva tiene una larga historia. Existe una concurrida lista de científicos que estuvieron en la cárcel y otra en la que figuran aquellos que contribuyeron a sacarlos de la misma y con ello a salvarles la vida. En nuestro siglo hemos sido testigos de cómo el físico Lev Landau estuvo encarcelado en la Unión Soviética y Pyotr Kapitsa arriesgó su vida apelando a Stalin para que pusiera en libertad al primero. Hemos visto al matemático André Weil cumpliendo condena en una cárcel finlandesa durante la guerra de Invierno de 1939-1940, y a Lars Ahlfors salvándole la vida. El momento más sublime en la historia del Institute for Advanced Study, donde yo trabajo, se produjo cuando nombramos miembro del instituto al matemático Chandler Davis, con el apoyo financiero que nos proporcionaba el gobierno de Estados Unidos a través de la National Science Foundation. Davis fue entonces

Freeman Dyson perturbare el universo