Why did you vote for REST?

REST (Representational State Transfer) describes the set of constraints that can be applied to a web service's architecture. A RESTful web service is one that properly adheres to these constraints.

1

Votes

Scalability

A RESTful web service is able to scale well partially because it can take advantage of the caching by clients and intermediate nodes that is provided out of the box by HTTP.This caching can only be achieved by requiring cacheable request types to be idempotent (produce the same result when called multiple times), and by requiring that the server be stateless (i.e., not generate responses based on session/per-connection state). When these constraints apply, all information that determines a response is contained in the request, and so intermediate nodes such as proxies can safely return cached results, provided that the request is the same, without knowing anything else about the end server. Similarly, idempotence allows for actions be performed multiple times, such as in the case of a failed connection, without fear of adverse effects. This is particularly useful not only for GET requests, but for PUT and DELETE requests, which allow for clients to predictably re-request for a change on the server.A RESTful web service, by virtue of not generating responses based on per-connection state, also only needs to scale its usage of hardware resources with the data provided by the service, not based on the number of concurrent connections.

1

Votes

Ease of Testing/Portability

Because clients and servers need to know nothing of eachother aside from a shared media type, they are completely decoupled from eachother, and so development of alternative clients is simplified - new clients need only support a shared media type. Servers may do their part in making client development easier by providing commonly implemented or well-specified media types that are easy to consume.RESTful web services are also particularly easy to test. As with in purely functional programming, the removal of a degree of side effects provides for much more testable interfaces, as output is predictable, consistent, and requires no set-up.Additionally, all RESTful web services can be tested at a high level with the same tools (e.g., curl). This benefit is primarily derived from resource-based addressing (URIs), and the fact that HTTP provides a standard generic interface for operating on those resources (HTTP verbs).

0

Votes

Extensibility and Discoverability

A RESTful web service is able to be extended dynamically, with minimal coordination between the client and server, because resources are discovered dynamically by clients. This is particularly a benefit over most RPC implementations, as even small changes in the interface to an RPC API can break clients.This is achieved through the use of hypermedia formats - formats that contain links. If clients don't rely on being able to parse or compose URIs, and instead, sufficiently descriptive hypermedia formats are used, a server can add new features (resources) by simply describing and linking to them.Similarly, as HTTP provides content negotiation, a RESTful API is able to support multiple representations of a resource - this allows for clients and servers to add and deprecate formats as they please, without breakage, so long as they continue to share at least one common media type. This is particularly useful for extending beyond the capabilities provided by a particular media type.

Why did you vote for SOAP?

  • Advantages over REST
  • Simple Architecture
  • Portability
  • Code Generation
  • Benefits of XML
  • Add Another Pro

SOAP is a data exchange protocol specification based on XML that supports both structured RPC, as well as more dynamic document-style messaging. It is particularly a good solution for services that would benefit more from flexibility in transport protocols than from gaining the benefits of adherence to a single protocol.

0

Votes

Advantages over REST

REST's benefits require strict adherance to constraints that are difficult to statically determine, which has resulted in many web services which intend to be RESTful, but fail, and as such fail to receive the benefits of REST. This can have some particularly negative effects:Content may be cached that should not be, leaving clients with stale data.Media types may be insufficiently specified, leaving clients coupled to the server and unable to discover new features. This is particularly common, as a content type of JSON or XML is generally of insufficient specificity to fully describe the media type and the relationships of links.Clients assuming a stateless server with idempotent GET/PUT/DELETE methods may make multiple requests to a server under these assumptions, causing adverse effects to the server state, or over-utilizing server resources.A service implemented over HTTP that fails to meet REST's requirements gains very little over SOAP, while losing many of its benefits.

0

Votes

Simple Architecture

SOAP's flexibility stems much from its simplicity. As an example, REST requires services to be organized around a Resource Oriented Architecture (ROA) in order to realize a set of benefits specific to HTTP. SOAP, on the other hand, does not heavily constrain the architecture of services built on it, as it is intended to work across a variety of protocols. This means that SOAP is an excellent solution for services that do not map well to ROA, such as those that require transaction semantics, those that would not likely make much use of HTTP specific features (e.g., cacheing and content-type negotiation) such as those that expose a computational resource (RPC), or for integrating multiple systems, which would benefit more from asynchronous messaging/callback semantics.

0

Votes

Portability

While SOAP is commonly implemented over HTTP, SOAP messages do not rely on features of any particular protocol. This means that SOAP services can be tunnelled over a variety of transport protocols aside from HTTP, such as SMTP. Beyond this, SOAP is not restricted to client-server architectures, and so may be used to implement services such as push notifications when used outside of HTTP.

Why did you vote for Apache Thrift?

  • Easy to read definition files
  • Simple Interface Definition Language (IDL)
  • Support for Multiple Programming Languages
  • Open Source (Apache 2.0)
  • The Choice of FaceBook
  • Includes built in language bindings for most popular languages
  • Add Another Pro

Apache Thrift is a framework, originally developed by Facebook, for building cross platform services over HTTP. Thrift development involves writing language agnostic service definition files and then generating stubs in the implementing language.

1

Votes

Easy to read definition files

While SOAP's WSDL documents are fairly verbose, Thrift files tend to be smaller and more straightforward.

0

Votes

Simple Interface Definition Language (IDL)

The IDL for Thrift looks quite similar to JSON / is comfortably human readable.

0

Votes

Support for Multiple Programming Languages

C++C#CocoaDelphiErlangHaskellJavaJavaScriptNode.jsOCamlPerlPHPPythonRubySmalltalk

Why did you vote for Apache Avro?

Whilst similar to Thrift and Protocol Buffers in sending binary data structures over http, Avro introduces additional flexibility which stands it in good stead to replace these older technologies. The technology is relatively young having been first released in 2009.

0

Votes

Dynamic Typing

The data structure's schema is encoded in the message alongside its data, allowing you to easily amend the data structure and have this continue to be understood by other systems. This also avoids the need for versioning, as the data's related structure can be seen directly.

Add Another Pro to Apache Avro

Why did you vote for Protocol Buffer?

  • Versioning
  • No Parsing Overhead
  • Composite Type Extensions
  • Open Source (BSD-3)
  • Reliable
  • Support for JavaScript
  • Support for Java, C++ and Python
  • Third Party Support for Multiple Programming Languages
  • The Choice of Google
  • Add Another Pro

Protocol Buffers were originally designed by Google in 2001 and later released to the open source community in 2008.

0

Votes

Versioning

The protocol includes versioning, allowing clients on older versions of code to continue to communicate with an upgraded server (i.e. clients and servers don't need to be upgraded in unison).

0

Votes

No Parsing Overhead

Unlike JSON and XML, because data is exchanged in binary, there is little to no parsing overhead, resulting in significant performance gains.

0

Votes

Composite Type Extensions

A range of addresses can be declared as available without further definition. This allows third parties to use these spare fields for their custom requirements.

Why did you vote for Hessian?

Hessian is a protocol for services over HTTP. Unlike most other web service protocols, Hessian exchanges binary data instead of XML or JSON documents.

0

Votes

Binary exchange format means messages are efficient

If you've ever wondered how much of your bandwidth is eaten up by XML closing tags, then you might just like Hessian.

Add Another Pro to Hessian

Are We Missing Something?