Answered by:
Submitting questions
Question
-
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, May 12, 2012 6:25 PM
- Moved by Mike Kinsman Monday, May 14, 2012 8:30 PM Forums issue (From:TechNet Website Feedback)
Answers
-
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 Wednesday, June 6, 2012 12:40 AM
- Marked as answer by Gerry C J Cornell Wednesday, June 6, 2012 2:50 PM
All replies
-
-
- Proposed as answer by Ed Price - MSFTMicrosoft employee Sunday, May 27, 2012 10:53 PM
- Marked as answer by Ed Price - MSFTMicrosoft employee Tuesday, June 5, 2012 7:51 PM
- Unmarked as answer by Gerry C J Cornell Tuesday, June 5, 2012 9:04 PM
- Unproposed as answer by Ed Price - MSFTMicrosoft employee Tuesday, June 5, 2012 9:33 PM
-
-
-
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?
- BizTalk Server and ReST
- Scenario for this Article
- How to Use this Article
- Set up the Design-time
- Deploy the Solution
- Configure the BizTalk Server Application
- Test the Solution
- 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:
- 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:
<?xmlversion="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope
"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding "><soap:bodypb="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 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:
- Create a request message that has all the required attributes such as HTTP verb, any parameters required to frame the URL, etc.
- Create a message inspector to alter the request message using the attributes specified in the request message.
- Create an endpoint behavior to apply the message inspector to the client endpoint.
- 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)
-
-
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?
- BizTalk Server and ReST
- Scenario for this Article
- How to Use this Article
- Set up the Design-time
- Deploy the Solution
- Configure the BizTalk Server Application
- Test the Solution
- 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:
- 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)
-
-
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?
- BizTalk Server and ReST
- Scenario for this Article
- How to Use this Article
- Set up the Design-time
- Deploy the Solution
- Configure the BizTalk Server Application
- Test the Solution
- 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:
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)
-
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?
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)
-
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?
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)
-
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?
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)
-
-
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?
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)
-
- Edited by Ed Price - MSFTMicrosoft employee Tuesday, June 5, 2012 11:17 PM
-
-
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?
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)
-
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?
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)
-
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?
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)
-
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?
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:
- 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. when the request message 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 Tuesday, June 5, 2012 11:05 PM
-
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 transportEd Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
-
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 transportIn 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 transportEd Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
-
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 transportIn 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 transportwhen the request message 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 Wednesday, June 6, 2012 12:00 AM
-
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)
-
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 Wednesday, June 6, 2012 12:40 AM
- Marked as answer by Gerry C J Cornell Wednesday, June 6, 2012 2:50 PM
-
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
