way to early

Here is an article about mobile 2.0. However I personally think we haven´t even seen 1.0
yet: http://www.readwriteweb.com/archives/understanding_mobile_2.php

Webservices

More and more companies are analyzing ways to open up part of their data and functionalities by offering webservices for developers. Webservices can deliver great benefits to your company. Hhowever it really depends on your business model and the data you offer and you should do a detailed analysis and conceptual analysis about what you are planning to offer and in which way or format.

In case you concider your web offering as part of the Web 2.0 hype, webservice are essential for you and include the following opportunities:

- leverage a wide-range of innovative thinkers and developers to create new applications
- partner with other companies to create co-offerings or mashups
- extend the reach of your platform and data into various technological channels
- gain new customers
- test new functionalities

You can find a nice overview about existing webservices on this site:

http://www.programmableweb.com/matrix

Most of the time a good webservice supports two protocols:

1. XML/HTTPs: With a XML API, the request interface is an XML document. Each request is composed of XML elements that specify the request parameters (e.g., the properties of an item to be listed and additional processing instructions).
With a XML API, the developers application builds the request as an XML string, sets a number of HTTP headers, and sends the request to the platform using the HTTPS protocol. After processing the request, the server sends a response back to the developers application, also via HTTPS. This response consists of an XML document containing the data that resulted from the original request. The developers application then parses the XML to extract the data.

2. SOAP: With a SOAP API, the request interface is an object in the developers application's native programming language. The developer uses a third-party SOAP client to generate business-object interfaces and network stubs from a WSDL document that specifies the message schema, the service address (SOAP gateway URL), and other information. The developers application works with data in the form of object properties, and it sends and receives the data by calling object methods. The developers SOAP client handles the details of building the SOAP request and sending it to the platform, and converting the response back to an object that is easy to work with. This frees the developer from the need to build and parse XML documents himself, so he can focus on managing and presenting the data itself. By simplifying the way the developer accesses data, a SOAP API helps the developer to get his applications up and running more quickly and to adapt more easily to changes.
A SOAP API is built on open standards like SOAP and WSDL. These standards are supported by a wide-range of development tools on a variety of platforms.
Both a XML API and a SOAP API often share the same schema, so the basic format of the input and output data is the same no matter which API the developer uses. Regardless of whether the developers are using a SOAP API or the XML API, they are accessing the same functionality and data. Thus, they can choose to use one or the other or both—whichever approach is best for them.

Go to http://developer.ebay.com/ to see one of the best practices in the internet industry - no joke! Try it.

Video über den Versandmanager von eBay

Hab mich mal wieder breit schlagen lassen und ein Video über die neuen Versandoptionen von eBay abgedreht ;-)