I have a problem with my SOAP-Service of my local
Dynamics CRM 2011 installed on my Windows Server 2008 R2 server.
If I call my SOAP-Service with
"http://crmdevsvr/Contoso/XRMServices/2011/Organization.svc"
or
"http://crmdevsvr/Contoso/XRMServices/2011/Organization.svc?wsdl"
It becomes a response.
Otherwise, if I call my SOAP-Service with my Silverlight-Resource, it builts internal with the function
GetSoapService() a URL
"Uri serviceUrl = CombineUrl(GetServerBaseUrl(), "/XRMServices/2011/Organization.svc/web");"
When I try to call the URL it doesn't work:
"http://crmdevsvr/Contoso/XRMServices/2011/Organization.svc/web"
Now, the funny (or not) problem is, that the URL with end of /web only works sometimes.
What's the meaning of /web at the end of the url?
I worked with the /web endpoint a while back, here is my understanding:
The OrganizationService is a server side endpoint, which means you need to reference it in your server side code first before you can call the web method. You can do this by adding the dll or the web reference to your project.
If you want to call the web method from client side, you need to use the /web one. It basically is a wrapper of the OrganizationService methods for JavaScript and Silverlight.
Related
I wanted to use vs code's extension REST client for testing purposes. So I used a curl of an existing API running on my local machine. But instead of JSON, I got HTML as a response. The curl works as expected in the terminal but not with the extension.
The same Behaviour is with another extension named Thunder Client.
Postman is getting JSON responses for the same API I believe that issue lies within vs code itself, I just don't know how to resolve it.
According to this article:
https://softwareengineering.stackexchange.com/questions/207835/is-it-ok-to-return-html-from-a-json-api
If you have declared you only accept one format in the header then the service should only send back that format or throw an error. If you have not put an ACCEPT in the header, the the service may send back whatever.
Check what is in the ACCEPT header:
But also check how Thunder Client translates the call in powershell:
I see that in my call the response is translated to JSON. I would guess that most REST clients are assuming that users want to work in JSON. Maybe that's what your two REST clients are doing?
I am calling a REST based service API from a ASP.NET 4.0 Webforms application.
The REST service requires HTTP Basic Auth and this has worked just fine so far. I'm using this code snippet to define my credentials for my HttpWebRequest object (serviceUsername, serviceUserPassword and serviceUrl are strings being passed in):
NetworkCredential credentials = new NetworkCredential(serviceUsername, serviceUserPassword);
HttpWebRequest httpReq = WebRequest.Create(serviceUrl) as HttpWebRequest;
httpReq.Credentials = credentials;
httpReq.Method = "GET";
httpReq.Accept = "application/json";
and then I fire off my request.
Today, suddenly, for one customer, things went haywire. Nothing seemed to work anymore - all my calls were rejected with a HTTP 401 - Unauthorized - even though, using the same URL and credentials, I was able to call this REST API from Fiddler.
The ultimate reason was a £ character in the password......
So Fiddler seems to have handled that gracefully, somehow - while ASP.NET falls flat on its nose. What extra step do I need to do in order for ASP.NET 4.0 to also work gracefully even if my customer decides to put a pound symbol in their (probably machine-generated) password? Any tricks or way to handle this?
I have coded a web application that runs on IIS Express. I want to send large data set to server(over 4MB) and get response. (I have implemented this as a REST service).
When i tried ,i realize that I can only have 311bytes long URL.
So how can i change that?
as i know IE allows 2083 length URL as default. and there should be a way to configure IIS express via web.config or applicationhost.config right?
can anybody help me?
You need to use an http post verb to send the data, instead of trying to send it encoded in the URL as a GET. In straight HTML, this would involve having a form tag with a submit button. What framework are you coding this in? (asp.net, mvc, php, etc?)
I'm making a ajax request with type:'DELETE' but somehow the request is not going inside the ServeResources(request,response) method (overridden from GenericPortlet class).
does anyone has an idea that why "Delete" and "Put" are not working with portal application(JSR 286) and How to get rid of that?
Thanks,
HTTP PUT/DELETE are some what protected methods, most of the web/application servers disable these methods by default, that could be the reason why you are not seeing your requests on server side. AFAIK it is independent of portal environment and handled by web/application server. You need to do some configuration changes on your server.
Why does using Fiddler break my site sometimes on page transitions.
After a server side redirect -- in the http response (as found in Fiddler) I get this:
Object moved
Object moved to here.
The site is an ASP.NET 1.1 / VB.NET 1.1 [sic] site.
Why doesnt Fiddler just go there for me? i dont get it.
I'm fine with this issue when developing but I'm worried that other proxy servers might cause this issue for 'real customers'. Im not even clear exactly what is going on.
That's actually what Response.Redirect does. It sends a 302 - Object moved response to the user-agent. The user-agent then automatically goes to the URL specified in the 302 response. If you need a real server-side redirect without round-tripping to the client, try Server.Transfer.
If you merely constructed the request using the request builder, you're not going to see Fiddler automatically follow the returned redirect.
In contrast, if you are using IE or another browser, it will generally check the redirect header and follow it.
For IE specifically, I believe there's a timing corner case where the browser will fail to follow the redirect in obscure situations. You can often fix this by clicking Tools / Fiddler Options, and enabling both the "Server" and "Client" socket reuse settings.
Thanks user15310, it works with Server.Transfer
Server.Transfer("newpage.aspx", true);
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
Read more here:
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm