I am confused on one thing. As I have read web services use SOAP protocol for communication and it is an XML based protocol; I was expecting the classical HelloWorld method on an asp.net web service to return an xml based data.
But when I checked with Fiddler i see that the Response Textview has a JSON string instead of an XML structure like:
{"d":"Hello World"}
Does this mean that asp.net web-service implementation returns 'string' types embedded as a value of a property called 'd' ?
Web services don't have to use SOAP as the protocol. The WCF lets you use all sorts of protocols for your web services. SOAP and JSON are just 2 of the options.
ASMX services return JSON if you request them via POST, with a content-type containing application/json. More info here: http://encosia.com/2010/03/03/asmx-and-json-common-mistakes-and-misconceptions/
Their return value isn't limited to just strings either. If you return a collection type, you'll get a JSON array. If you return a server-side class, that will be serialized into the correct JSON key/value pairs to represent that object.
The .d is sort of an orthogonal issue. It's a security feature to thwart a particular attack against JavaScript's Array constructor. More here: http://encosia.com/2009/02/10/a-breaking-change-between-versions-of-aspnet-ajax/
Ok. I have found my answer, here:
"ASP.NET AJAX sends JSON messages to Web Services as opposed to the standard Simple Object Access Protocol (SOAP) calls typically associated with Web Services. This results in smaller request and response messages overall. It also allows for more efficient client-side processing of data since the ASP.NET AJAX JavaScript library is optimized to work with JSON objects. "
More details in :
http://www.asp.net/ajax/tutorials/understanding-asp-net-ajax-web-services
As you can see here JSON responses are supported by recent releases of the .NET Framework.
Related
I don't have something in particular that I need to implement, I am just trying to understand some concepts.
As far as I know, .NET web method (for example), that is inside a web service, is using the SOAP protocol. that means that the data received to the server needs to be in XML format, and the data that is returned from the web method should also be in XML format.
I know I can write something like this:
[WebMethod]
public static Object someMethod(Object josn)
{
Console.Write(json("someProperty"));
return new {name = "John"}
}
I know that data sent back to the client is in JSON format...
but if we are using the SOAP protocol, shouldn't it return XML?
I want to understand what is happening behind the scene or what am I missing, does the request was sent in xml format and the .NET framework knows how to extract the parameters that were sent, if so- how can I retrieve the full xml that represents the request made?
What you are referring to is called the SOAP envelope. Take a look here:
Sample SOAP Envelope
One of the easiest ways to see the SOAP envelope that is being used in a request or response is to use Fiddler or Postman.
EDIT
Here's an example of WCF SOAP envelope with JSON (not sure if you are using WCF or the old .NET Web Service with ASMX files):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header></s:Header>
<s:Body>[{"DateOfBirth":"\/Date(286801200000+1300)\/","FirstName":"Foo","Id":1,"LastName":"Bar"},{"DateOfBirth":"\/Date(333720000000+1200)\/","FirstName":"Foo","Id":1,"LastName":"Bar"}]</s:Body>
</s:Envelope>
I have to write sign on peoplecode to make a service call by passing token (sent from third party) to API and get the responce (if token is valid responce will have username) in json format to create a PS_TOKEN.
I am fresher to peoplecode. How can I run HTTP POST request by passing token and get the response using Peoplecode?
You would create a synchronous service operation in the Integration Broker. The Integration Broker works best if you are sending XML or JSON. If this is just a regular HTTP POST with fields then it can cause some issues with the Integration Broker. I had a similar case and could not get the basic HTTP Post to work but instead ended up using HTTP POST multipart/form-data and was able to get that to work.
Steps I had to do to make this work.
Create a Message (document based or rowset based are both possible)
Create Service Operation and related objects
Create Transform App Engine to convert the Message to a HTTP POST multipart/form-data
Create a routing and modify the connector properties to send the content type of multipart/form-data. Also call the Transform app engine as part of the routing.
The issue with a application/x-www-form-urlencoded POST is that it seems PeopleSoft does another url encoding after the Transform, which is the last time you can touch the output with code. This final url encoding was encoding the = sign in the form post which made the format invalid.
Your other option would be to write this is Java and call the Java class from within PeopleSoft (or mix the Java objects in with PeopleCode). If you choose to go this way then the App Server needs to have connectivity to your authentication server. My only experience with this is I had a client that used this approach and had issues under heavy load. It was never determined the cause of the performance issue, they switched to LDAP instead to resolve the issue.
I am creating a WCF service and I am planning to set the message format as JSON. But when I use BasicHttpBinding, I get the response and request in XML format. I am not sure does that mean this WebMessageFormat.Json can be used only in WEBHttpBinding (REST)? I have an understanding that SOAP uses only XML but this MessageFormat attribute arise a question in me whether JSON format can be used across all binding.
I am building an asp.net (MVC/Web API) application where I will be returning arbitrary data from a view, and the type of data is not known at design time.
Specifically, the user will specify some URI, and my back end will fetch that uri. The data returned might be a straight text/html web page, or it could return an RSS feed with a text/rss+xml content type, or it might return a JSON payload, etc. I won't know the format of the data until runtime, after I fetch the data and inspect the content-type.
My objective (for all intents and purposes - irrelevant detail omitted) is to echo that payload back to the user. I will of course set the proper content type in the response as well as any relevant headers (like cookies) that were in the original response.
What is the best practice for returning the data from the controller action to accommodate this? If I were using ASP.NET Web API for example, could I just send (and how?) an arbitrary blob (I use 'blob' for lack of a better term - what I mean is that I will echo the payload of the http response I got when I made the call to the resource) back to the client (of course with the content-type set properly)?
In summary my specific questions are:
Should I use ASP.NET MVC or ASP.NET Web API to accomplish this?
If ASP.NET Web API (I assuming that is the proper direction), how do I echo an arbitrary stream (I say stream rather than string, because it could be binary) of data (of which I do not know the content-type until runtime) to the client?
A lot of web applications must be used the specified REST service. This REST service uses currently the informations only from javax.servlet.http.HttpServletRequest. This HttpServletRequest may be contain the specific cookie and other parameters.
I'm try to use the (REST) client API form JERSEY to realize a client, that will build the REST requests. This client will be called within custom web filter, that will be registered by web.xml of each web application.
Currently i have the following problem: i'm don't know, howto transmitt the HttpServletRequest during call of the REST Service....
Thx for your help....
So if I understand correctly, you want receive a request in any of the web applications, and then you want to forward this request to the REST web service?
If so, you will need to serialize the request to make it transportable. You could also create a class that is able to hold the data that you need from the javax.servlet.http.HttpServletRequest and then serialize it into XML or JSON.
If you have the request in a more transportable format, you can pass it to your REST service via a #HeaderParam or as the request body (I would prefer the latter).