This is the FAQ for the Apex REST API Webinar.
All Developer Edition orgs have been automatically enabled with Apex REST. Simply log into your DE org and you should have access to the Apex REST feature.
No. A single @RestResource class cannot have multiple methods annotated with the same HTTP request method. Thus, two methods, both annotated with @HttpGet are not allowed. You can of couse include multiple methods that are annotated with different HTTP request methods in the same class (for e.g. you can have a @HttpGet method, another @HttpPost method etc.)
Packaging is not currently available for Apex REST during the Developer Preview period. ISVs are free to experiment and test the Apex REST feature in a DE org, but they will not be able to add it a Managed or Unmanaged Package for now. Packaging support for Apex REST is being actively worked upon and will be available in the near future.
Not natively. De/serialization support is only available for XML and JSON data formats. You could however return data in a custom JSONP format by using the RestResponse class (instead of defining a return type for the method).
Not during the Developer Preview period. During Developer Preview, you can use
as method parameter or return types. Remember however, that you always have the choice of not using the automatic de/serialization offered by the platform and perform your own custom parsing on the raw (i.e. in Blob format) incoming request data using the RestRequest class.
All the standard Apex Governor limits apply to an Apex REST class (See the [docs http://www.salesforce.com/us/developer/docs/apexcode/index_Left.htm#StartTopic=Content/apex_gov_limits.htm]). Apex REST does not add any new governor limits. In addition, each call to an Apex REST service counts against the API limit for the respective Org (similar to Apex SOAP).
On the discussion boards.
Not at this time
Yes, you can easily achive that if you structure your code correctly. For example, you could encapsulate all your custom business logic is a separate class (say 'MyCustomLogic') and then create 2 Apex classes - one 'MyCustomSOAPSvc' class that uses the webservice keyword (that would make it available as a SOAP service) and another 'MyCustomRESTSvc' class that uses the @RestResource annotation (which would make it available as a RESTful service). Each of these classes could simply invoke the appropriate function on the the 'MyCustomSOAPSvc' class to perform the same business action and return the appropriate response.
Just the wildcard currently.
It's up to you. Normally PATCH is for a partial update of a resource and POST is for inserting a new resource.