Submitting questions

Ask a question

Saturday, 12 May 2012 6:10 PM

0
I encountered great difficulty trying to submit a question to the Windows 7 Miscellaneous forum.

On something like the fourth attempt I got a response "Body 4 to 60,000 characters"! The earlier attempts to submit timed out. The word count from Word 2010 said Characters (with spaces) 28,867. Why would the submission not complete?

I have since submitted a significantly shortened post which was accepted.

TIA, Gerry
- Edited by Gerry C J Cornell Saturday, 12 May 2012 6:25 PM
- Moved by Mike KinsmanMicrosoft Contingent Staff Monday, 14 May 2012 8:30 PM Forums issue (From:TechNet Website Feedback)
- Reply
- Quote

All Replies

Monday, 14 May 2012 8:30 PM

1

Moving this to forums issues.

Thanks,
Mike
MSDN and TechNet Subscriptions Support
Read the Subscriptions Blog!
- Reply
- Quote
Wednesday, 23 May 2012 7:58 PM

Owner

0
Please link to the forum and thread.

Has anyone else had a similar issue?

I can't repro this in other forums.

Thanks!
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Proposed As Answer by Ed Price - MSFTMicrosoft Employee, Owner Sunday, 27 May 2012 10:53 PM
- Marked As Answer by Ed Price - MSFTMicrosoft Employee, Owner Tuesday, 5 June 2012 7:51 PM
- Unmarked As Answer by Gerry C J Cornell Tuesday, 5 June 2012 9:04 PM
- Unproposed As Answer by Ed Price - MSFTMicrosoft Employee, Owner Tuesday, 5 June 2012 9:33 PM
- Reply
- Quote
Tuesday, 5 June 2012 9:05 PM

0

Ed

How does your message qualify as an answer?
Hope this helps, Gerry
- Reply
- Quote
Tuesday, 5 June 2012 9:15 PM

Owner

0

Hey, you responded! Please leave a link to the forum and thread.

Let's try to repro this.

So the editor says the limit is 60,000 characters, but you reached the limit with 28K?

We can test that.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:18 PM

Owner

0
7K character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<input id="ctl00_ctl00_content_content_ctl00_w_6615_ctl01_ctl01_Value" type="hidden" value="5" />
This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:
- Rupert Benbrook, Senior Consultant, BizTalk Server
- Delbert Murphy, TSP, BizTalk Server
- Anand Bheemrajaiah, BizTalk Server Product Team
- Ankit Raizada, BizTalk Server Product Team
- Shailesh Agre, BizTalk Server PSS
Contents
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:
- Every unique entity is an identifiable resource. A resource could be an XML document, a website, etc.
- URLs identify unique resources. Every resource can be uniquely identified through a URL.
Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:
http://www.contoso.com/Customer/Details/9999
Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
```
<?xml version="1.0"?> 
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope  " soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding  "> 
 <soap:body pb="http://www.contoso.com/customer  "> 
  <GetDetails> 
   <ID>9999</ID> 
  </GetDetails> 
 </soap:Body> 
</soap:Envelope>
```
In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:
http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith
To know more about ReST, you might want to go through the following links:
One of the real-life examples of ReST is the Twitter API .

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
- Exchange non-SOAP messages.
- Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following:
- The HTTP method to use in the request (GET, PUT, POST, DELETE).
- How to form the request URL from operation method parameters (URL path and query string template).
- How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through Message Inspectors . A message inspector is an extension to the client runtime and is configured as a behavior. A behavior, in turn, is added to a behavior extension element. This behavior extension element is registered in the machine.config with an element name, which makes it available to be configured as a custom behavior on a WCF-Custom port. For more information, see Extending WCF with Custom Behaviors .

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:
1. Create a request message that has all the required attributes such as HTTP verb, any parameters required to frame the URL, etc.
2. Create a message inspector to alter the request message using the attributes specified in the request message.
3. Create an endpoint behavior to apply the message inspector to the client endpoint.
4. Create a behavior extension element to enable configuration of the endpoint behavior.
Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:20 PM

Owner

0

I tried a 41K character test and got the same popup (saying to use between 4 and 60K characters).

Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:22 PM

Owner

0

I tried a 29K character test and got the same popup.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:25 PM

Owner

0

I tried a 24K character test and got the same popup.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:25 PM

Answerer

0

So, you're confirming a bug.
For every expert, there is an equal and opposite expert. - Becker's Law

My blog
- Reply
- Quote
Tuesday, 5 June 2012 9:27 PM

Owner

0

Yes, defining it.

Gerry, how many characters was your shorter version? Can you link to it?
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:27 PM

Owner

0

I tried a 19K character test and received the same popup.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:31 PM

Owner

0

So on a 14K character test I got a different popup... "Unexpected error."

Is that unique to this thread or specific to the number of characters?
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:34 PM

Owner

0

I confirmed the same behavior in a new thread. 14K characters gives you the Unexpected Error popup instead.

Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:36 PM

Owner

0

11K characters gets you the same Unexpected Error popup.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:41 PM

Owner

0

So a 9K character test has a long delay and still gives the Unexpected Error popup.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:53 PM

Owner

0

8K character test has the same results.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:58 PM

Owner

0

A 7,400 character test also gives the Unexpected Error popup. Hmmm. I had a 7K+ character test above that worked.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 9:59 PM

Owner

0
7,900 character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:
- Rupert Benbrook, Senior Consultant, BizTalk Server
- Delbert Murphy, TSP, BizTalk Server
- Anand Bheemrajaiah, BizTalk Server Product Team
- Ankit Raizada, BizTalk Server Product Team
- Shailesh Agre, BizTalk Server PSS
Contents
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:
- Every unique entity is an identifiable resource. A resource could be an XML document, a website, etc.
- URLs identify unique resources. Every resource can be uniquely identified through a URL.
Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange non-SOAP messages.
Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following:

The HTTP method to use in the request (GET, PUT, POST, DELETE).
How to form the request URL from operation method parameters (URL path and query string template).
How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

29. Create a request message that has all the required attributes such as HTTP verb, any parameters required to frame the URL, etc.

30. Create a message inspector to alter the request message using the attributes specified in the request message.

31. Create an endpoint behavior to apply the message inspector to the client endpoint.

32. Create a behavior extension element to enable configuration of the endpoint behavior.

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>
A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 10:03 PM

Answerer

0

How are you counting the number of characters? I've been able to post 3K words text (~30K characters).
For every expert, there is an equal and opposite expert. - Becker's Law

My blog
- Reply
- Quote
Tuesday, 5 June 2012 10:38 PM

Owner

0
11K character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:
- Rupert Benbrook, Senior Consultant, BizTalk Server
- Delbert Murphy, TSP, BizTalk Server
- Anand Bheemrajaiah, BizTalk Server Product Team
- Ankit Raizada, BizTalk Server Product Team
- Shailesh Agre, BizTalk Server PSS
Contents
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange non-SOAP messages.
Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>
A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 10:40 PM

Owner

0
13,200 character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:

Shailesh Agre, BizTalk Server PSS

Contents

What is ReST?
- Download the Sample
- What Next?
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange non-SOAP messages.
Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>
A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 10:42 PM

Owner

0
16,800 character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:

Shailesh Agre, BizTalk Server PSS

Contents

What is ReST?
- Download the Sample
- What Next?
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 10:42 PM

Owner

0
22K character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:

Shailesh Agre, BizTalk Server PSS

Contents

What is ReST?
- Download the Sample
- What Next?
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 10:46 PM

Answerer

0

Ok, but you never answered my question.
For every expert, there is an equal and opposite expert. - Becker's Law

My blog
- Reply
- Quote
Tuesday, 5 June 2012 10:47 PM

Owner

0

So this seems like it might be a bit limit, meaning that pasting in heavy HTML greatly limits your characters to 6K or 7K.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 10:48 PM

Owner

0
29,400 character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:

Shailesh Agre, BizTalk Server PSS

Contents

What is ReST?
- Download the Sample
- What Next?
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 10:52 PM

Owner

0
Okay. I got the "Body must be 4 to 60000 characters long" at 45K characters, even with the improved HTML/formatting.

Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Edited by Ed Price - MSFTMicrosoft Employee, Owner Tuesday, 5 June 2012 11:17 PM
- Reply
- Quote
Tuesday, 5 June 2012 10:54 PM

Owner

0
Same with...

38K

34,800

Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Edited by Ed Price - MSFTMicrosoft Employee, Owner Tuesday, 5 June 2012 10:55 PM
- Reply
- Quote
Tuesday, 5 June 2012 10:57 PM

Owner

0
30,300 character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:

Shailesh Agre, BizTalk Server PSS

Contents

What is ReST?
- Download the Sample
- What Next?
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 10:58 PM

Owner

0

Got the error at 31,700 characters.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 11:01 PM

Owner

0
30,900 character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:

Shailesh Agre, BizTalk Server PSS

Contents

What is ReST?
- Download the Sample
- What Next?
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 11:02 PM

Owner

0
31,100 character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:

Shailesh Agre, BizTalk Server PSS

Contents

What is ReST?
- Download the Sample
- What Next?
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
- RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- RESTful .NET (book) <wrap type="none"></wrap><anchorlock></anchorlock>
- Steps Toward the Glory or REST <wrap type="none"></wrap><anchorlock></anchorlock>
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 11:04 PM

Owner

0

31,400 character test failed.

Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 11:04 PM

Owner

0
31,328 character test:

Invoke ReSTful Web Services with BizTalk Server 2010

<wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><//span>

This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.

Acknowledgements

We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:

Shailesh Agre, BizTalk Server PSS

Contents

What is ReST?
- Download the Sample
- What Next?
What is ReST?

ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.

The two fundamental aspects of a ReST design pattern are:

Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
- Each customer is resource.
- Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:

http://www.contoso.com/Customer/Details/9999

Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>http://www.contoso.com/customer <wrap type="none"></wrap><anchorlock></anchorlock>RESTful Web Services (book) <wrap type="none"></wrap><anchorlock></anchorlock>

<soap:body pb="

  <GetDetails>

   <ID>9999</ID>

  </GetDetails>

</soap:Body>

</soap:Envelope>

In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.

ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:

http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith

To know more about ReST, you might want to go through the following links:
One of the real-life examples of ReST is the

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through

So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:

Scenario for this Article

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

In this article, we will use one of the Twitter ReST APIs that give us the

Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

BizTalk Server and ReST

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:

Exchange

Support GET, PUT, POST, and DELETE methods.

If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
Twitter API <wrap type="none"></wrap><anchorlock></anchorlock>Message Inspectors <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock> public timeline <wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock><wrap type="none"></wrap><anchorlock></anchorlock>A Brief Introduction to REST <wrap type="none"></wrap><anchorlock></anchorlock>
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Edited by Ed Price - MSFTMicrosoft Employee, Owner Tuesday, 5 June 2012 11:05 PM
- Reply
- Quote
Tuesday, 5 June 2012 11:19 PM

Owner

0

Okay. I submitted a bug request.

Thanks!
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 11:25 PM

Owner

0

Let's try 35K characters, stripped of formatting in Notepad:

Invoke ReSTful Web Services with BizTalk Server 2010
          <input id="ctl00_ctl00_content_content_ctl00_w_6615_ctl01_ctl01_Value" type="hidden" value="5" />
This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.
Acknowledgements
We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:
Shailesh Agre, BizTalk Server PSS
Contents
What is ReST?
• Download the Sample
• What Next?
What is ReST?
ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.
The two fundamental aspects of a ReST design pattern are:
Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
• Each customer is resource.
• Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:
http://www.contoso.com/Customer/Details/9999
Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope   " soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding   ">
<soap:body pb="http://www.contoso.com/customer   ">
<GetDetails>
   <ID>9999</ID>
</GetDetails>
</soap:Body>
</soap:Envelope>
In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.
ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:
http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith
To know more about ReST, you might want to go through the following links:
• A Brief Introduction to REST
• RESTful Web Services (book)
• RESTful .NET (book)
• Steps Toward the Glory or REST
One of the real-life examples of ReST is the Twitter API .
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through Message Inspectors . A message inspector is an extension to the client runtime and is configured as a behavior. A behavior, in turn, is added to a behavior extension element. This behavior extension element is registered in the machine.config with an element name, which makes it available to be configured as a custom behavior on a WCF-Custom port. For more information, see Extending WCF with Custom Behaviors .
So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:
Scenario for this Article
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport

Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 11:35 PM

Owner

0

Let's try 50K characters, stripped of formatting (via Notepad):

Invoke ReSTful Web Services with BizTalk Server 2010
          <input id="ctl00_ctl00_content_content_ctl00_w_6615_ctl01_ctl01_Value" type="hidden" value="5" />
This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.
Acknowledgements
We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:
Shailesh Agre, BizTalk Server PSS
Contents
What is ReST?
• Download the Sample
• What Next?
What is ReST?
ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.
The two fundamental aspects of a ReST design pattern are:
Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
• Each customer is resource.
• Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:
http://www.contoso.com/Customer/Details/9999
Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope   " soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding   ">
<soap:body pb="http://www.contoso.com/customer   ">
<GetDetails>
   <ID>9999</ID>
</GetDetails>
</soap:Body>
</soap:Envelope>
In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.
ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:
http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith
To know more about ReST, you might want to go through the following links:
• A Brief Introduction to REST
• RESTful Web Services (book)
• RESTful .NET (book)
• Steps Toward the Glory or REST
One of the real-life examples of ReST is the Twitter API .
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through Message Inspectors . A message inspector is an extension to the client runtime and is configured as a behavior. A behavior, in turn, is added to a behavior extension element. This behavior extension element is registered in the machine.config with an element name, which makes it available to be configured as a custom behavior on a WCF-Custom port. For more information, see Extending WCF with Custom Behaviors .
So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:
Scenario for this Article
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport

Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Tuesday, 5 June 2012 11:57 PM

Owner

0
56,600 character test:

Invoke ReSTful Web Services with BizTalk Server 2010
          <input id="ctl00_ctl00_content_content_ctl00_w_6615_ctl01_ctl01_Value" type="hidden" value="5" />
This article presents a workable solution for consuming ReSTful services using BizTalk Server 2010.
Acknowledgements
We in the BizTalk Server CCxG team gratefully acknowledge the contributions of the following individuals for providing their valuable inputs in setting up the end-to-end scenario used in this article:
Shailesh Agre, BizTalk Server PSS
Contents
What is ReST?
• Download the Sample
• What Next?
What is ReST?
ReST stands for Representational State Transfer and defines an architecture to create network applications, typically over the World Wide Web. In most cases, the protocol used for a ReST client-server communication is HTTP. An application that uses ReST architecture is called a ReSTful application. Such applications use HTTP requests to create, update, read, and delete data, thereby supporting all CRUD operations. These CRUD operations are performed by ReST by supporting the GET, PUT, POST, and DELETE methods.
The two fundamental aspects of a ReST design pattern are:
Let us understand this with an example. An organization "Contoso" has a significantly large customer base and wants to provide customers with the option to view their details as stored in Contoso's records. If Contoso decides to expose the customer details the ReSTful way, it would have to think on the lines of:
• Each customer is resource.
• Each customer can be identified by a unique URL.
Going by this theory, a URL that could probably provide details for a customer with ID = 9999 would look like:
http://www.contoso.com/Customer/Details/9999
Had there been no ReSTful way of retrieving customer details, one would have to send a SOAP request that would have probably looked like:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope   " soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding   ">
<soap:body pb="http://www.contoso.com/customer   ">
<GetDetails>
   <ID>9999</ID>
</GetDetails>
</soap:Body>
</soap:Envelope>
In the case of ReST, the URL is sent over an HTTP GET request to the server and the response is received in the form of raw data. In the traditional SOAP-way of invoking Web services, the XML request message is sent over an HTTP POST request to the server, and the response is embedded as the payload within the SOAP response envelope.
ReST URLs can also include parameters to handle more complicated requests. For example, to get customer details for John Smith, the URL might look like:
http://www.contoso.com/Customer/Details?firstName=John&lastName=Smith
To know more about ReST, you might want to go through the following links:
• A Brief Introduction to REST
• RESTful Web Services (book)
• RESTful .NET (book)
• Steps Toward the Glory or REST
One of the real-life examples of ReST is the Twitter API .
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
Now let us talk a little bit about the customization that would be required on the webHttpBinding. webHttpBinding is WCF-based. WCF enables you to alter messages before they are sent or after they are received through Message Inspectors . A message inspector is an extension to the client runtime and is configured as a behavior. A behavior, in turn, is added to a behavior extension element. This behavior extension element is registered in the machine.config with an element name, which makes it available to be configured as a custom behavior on a WCF-Custom port. For more information, see Extending WCF with Custom Behaviors .
So, to sum it up, to consume a ReSTful service with BizTalk Server, this is what we need to do:
Scenario for this Article
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
In this article, we will use one of the Twitter ReST APIs that give us the public timeline and user-specific timeline . In Twitter parlance, a timeline is the list of tweets. For a public timeline, the list includes the last 20 tweets from unprotected users. For a user-specific timeline, the list includes the last 20 tweets by a specific unprotected user. An unprotected user is someone who has opted to not make the tweets private while setting up the Twitter account. There are two main reasons for picking these two APIs: both support the GET method and both do not require authentication. In this article, we want to keep the focus on how to use the customizations discussed above to use BizTalk Server with ReST. Including authentication with ReST would dilute the focus of this article. Moreover, authentication with ReST could vary with the APIs being used and will have to be handled differently for different applications. For example, Twitter uses OAuth for authenticating applications.
Coming back to the scenario, the uber scenario for this article includes dropping a request message in a folder and out comes the list of tweets (for a public timeline or for a given user) in an e-mail. However, if you break this down into stages, this is what the scenario would look like:
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport

In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
BizTalk Server and ReST
In the previous section we saw how ReST is not SOAP and that ReST supports GET, PUT, POST, and DELETE methods. So, if one has to use ReST with BizTalk Server, the adapter to be used should be able to:
Exchange
Support GET, PUT, POST, and DELETE methods.
If we look at the adapters available with BizTalk Server 2010, only the HTTP adapter satisfies the first criteria but it does not support GET (it does support the POST method). Similarly, the webHttpBinding (that supports consuming and exposing ReSTful services) available with WCF-Custom adapter can send non-SOAP messages but that too has no way of specifying the HTTP verb to be used. All other adapters either do not support HTTP verbs or always exchange SOAP messages. So, there is no way to have an out-of-box BizTalk configuration to consume a ReSTful service. To use BizTalk Server with ReST, we'll have to do some customizations around HTTP adapter or the webHttpBinding of the WCF-Custom adapter. There is no prescribed way of doing customizations around the HTTP adapter. However, to the webHttpBinding, we can add some custom behaviors that when coupled with webHttpBinding enable BizTalk users to invoke and consume ReSTful services. Through these customizations, we can specify the following: How to encode the request body and decode the response.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport

when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport

when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport. message and frames the required HTTP transport
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.
With WCF-Custom port configuration, there's no way of specifying these customizations directly on the webHttpBinding. So, we'll have to put these values in the request message. After specifying the values as part of the request message and adding a custom behavior to the webHttpBinding, when the request message hits the WCF-Custom port with the webHttpBinding, the custom behavior extracts the values from the request message and frames the required HTTP transport.

Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Edited by Ed Price - MSFTMicrosoft Employee, Owner Wednesday, 6 June 2012 12:00 AM
- Reply
- Quote
Wednesday, 6 June 2012 12:03 AM

Owner

0

So I couldn't break 57,000 characters, but I got close. This is only possible with stripped formatting or if you wrote all the text originally in the editor. Pasting from another site or Word will give you bulky formatting and will limit your character max by a lot.
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Reply
- Quote
Wednesday, 6 June 2012 12:40 AM

Owner

1
I submitted this as a bug request to the forums team and am recommending the following error message instead:

“Body must be over 4 to 57000 characters long. If you are pasting in content, the extra HTML styles could reduce your character limit all the way down to about 7000 characters.”

I think that brings a lot more clarity to the issue.

Thanks!
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Proposed As Answer by Ed Price - MSFTMicrosoft Employee, Owner Wednesday, 6 June 2012 12:40 AM
- Marked As Answer by Gerry C J Cornell Wednesday, 6 June 2012 2:50 PM
- Reply
- Quote
Wednesday, 6 June 2012 2:50 PM

0

Ed

That is more like an answer.

The format capabilities in these Forums and Microsoft Answers is poor. You cannot easily spell check and a lot of answers are suitable for using canned responses with minimal alteration. This wastes a lot of contributors time. Using Word circumvents the issues.
Hope this helps, Gerry
- Reply
- Quote

Submitting questions

All Replies

7K character test:

Invoke ReSTful Web Services with BizTalk Server 2010

Acknowledgements

Contents

What is ReST?

BizTalk Server and ReST

Scenario for this Article