I use Postman to learn how to use API and i was trying to get list of projects only with clients. I tried make request with "archived: true" and it did work. But, when i try to use "contains-client: true", i get all projects, with and without client.
Related
I am new to Web API and the tutorial I was watching uses Fiddler to sniff and send request.
My question is how to use the post, put and delete methods without using fiddler and where are these usually used in the when creating in software development? Fiddler allows you to compose a request body how about the browser though?
I don't seem to understand why you are only able to use these on a sniffing tool. I understand that I am most probably speaking out of ignorance.
(This answer is not specific to ASP.NET)
To avoid any confusion, I'm assuming you understand this much about RESTful webservices:
If you are creating a new entity, use POST.
If you are reading an entity, use GET.
If you are updating an entity, use PUT.
If you are deleting an entity, use DELETE.
As you noticed, only the GET and POST methods can be used in plain web forms. AJAX, however, supports using any HTTP method. Therefore, to use the PUT and DELETE methods, send your data to the server using JavaScript methods such as XMLHttpRequest, the newer Fetch API or a convenient wrapper like jQuery's $.ajax. (There are many tutorials for whichever you pick.) For example, if you have a form of updated values, replace your input button with a button element that has a JavaScript click event handler. The same principle applies to a delete link, swap the href for a click event handler that makes an AJAX request to your server.
If you simply want to create requests using some tool, then you can use tools like Fiddler, Postman, curl, etc. - as you have stated, Fiddler can also be used to monitor as well as create requests.
If you want to go beyond that,
you have HttpClient, WebClient to build requests on your own, and for testing.
If you want to get "full control" then look into HttpWebRequest.
VS debugging tools will allow you to inspect the full flow - from request to response - using things like breakpoints, watch, etc.
See previous/other answers if you want to build/create requests client-side (Javascript / XMLHttpRequest)
Hth.
I am already using the standard WebAPI and returning JSON objects to my client. Now I saw an application that returned OData.
Can someone explain if there is any reason for me to use OData if I do not want to query my data from anything other than my own client running in the browser. Are there advantages that I could get through using OData ?
If you are only using your data in your own browser application, there is only few advantages to use OData in your situation:
OData is able to provide metadata about your service interface that can be used to generate client code to access the service. So if you have lots of client classes that you need to create, this could speed up your process. On the other hand, if you can share your classes between the server and an ASP.NET based client or if you only have a few classes, this might not be relevant in your situation.
Another - bigger - advantage in your situation is the support for generic queries against the service data. OData supports IQueryable so that you can decide on the client side on how to filter the data that the service provides. So you do not have to implement various actions or use query parameters to provide filtered data. This also means that if you need a new filter for your client, it is very likely that you do not have to change the server and can just put up the query on the client side. Possible filters include $filter expressions to filter the data, but also operations like $skip and $top that are useful when paging data. For details on OData and queries, see this link.
For a complete overview about OData and Web API see this link.
Here are few advantages of OData.
OData is a open protocol started by Microsoft is based on Rest Services so we can get data base on URL.
It suppport various protocol like http,atom,pub and also support JSON format.
No need to create proxy classes which we used to do it in web service.
You will able to write your own custom methods.
It is very light weight so the interaction between client and server will be fast compared to web service and other technologies.
Very simple to use.
Here are few reference links.
http://sandippatilprogrammer.wordpress.com/2013/12/03/what-is-odata-advantages-and-disadvantages/
http://geekswithblogs.net/venknar/archive/2010/07/08/introduction-odata.aspx
http://www.zdnet.com/blog/microsoft/why-microsofts-open-data-protocol-matters/12700
I agree with the answers already posted, but as an additional insight...
You mentioned that:
... if I do not want to query my data from anything other than my own
client running in the browser...
You may not wish to run it normally through anything but your own cilent, but using oData you could use other querying tools for debugging. For example LinqPad allows you to use oData endpoints (such as that provided by stackoverflow).
It's probably not a good enough reason to implement oData if you don't have another reason to do so, but it's an added bonus.
I'm receiving an error when I'm attempting to consume a web service:
Cannot read the token from the 'Timestamp' element with the 'http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' namespace for BinarySecretSecurityToken, with a '' ValueType.
Not quite sure
The client is an asp.net web application, making a call. From Wireshark, one can see the post going in, and the response coming back, but then it errors out like this.
To give some background, this is a WCF calling on a java served web service.
You may need to add a security timestamp soap header to the message. Look at this SO question where they had the opposite problem but it may be helpful to look at their configuration. Also, you may save yourself some grief if you can use one of the WCF Interop Express bindings for accessing a java service implementing WS-Security.
Is it required to use a RESTful
service to be able to make a ajax
call to a wcf service (for example: by using
WebInvoke attribute on Operation
contracts)
Once a service is made RESTful by adding a webHttp binding on the service host, can the host have other endpoints as well? (wsHttp or netTcp)
Is it required that the aspNetCompatibilityEnabled be set to true for a service that has webHttp binding (and can this setting coexist for other endpoints)
I understand I can use both JQuery and ScriptManager for making WCF calls on the client. Why should I use one over the other?
Answers
No.
AJAX is typically used for sending simple HTTP GET ("REST") requests. It doesn't have to be so. You could also format a payload using a SOAP envelope, and POST it to the endpoint. In that case the WCF service would have to be wsHttp or basicHttpBinding, at least. Here's an example of using VBScript to create and send a SOAP request, but you could do the same in Javascript. You can't use the more advanced SOAP extensions, like WS-Security, XML DigSig, and so on. Well, you could but it would be impractical. For example, I don't know of any XML canonicalization library in Javascript, which is essential for doing WS-Security or digital signatures. There are 17 similar obstacles. Result: you can't use the more advanced SOAP extensions when calling from Javascript.
.
If you use jQuery ajax, you'll need to use the beforeSend callback on the ajax request to set the SOAPAction header.
.
Having said that, it's a lot easier to process json in a Javascript program, than it is to walk the DOM of an XML document. In other words, you're better off using JSON/REST when connecting from Javascript to WCF, instead of SOAP. Sometimes it's not an option, I guess.
Yes
A WCF service can have multiple endpoints and they can listen on the same or different transports such as HTTP, net.tcp, net.pipe, or net.msmq.
No. aspNetCompatibilityEnabled just enables some ASMX-like features on the server. It affects how the service is designed, and it is independent of the message signature. It does preclude the use of non-HTTP protocols. For more on this, see Wenlong Dong's article.
as for which framework to use on the client - which is easier? I don't have experience with ScriptManager, but the decision criteria is pretty simple. jQuery works just fine, and is appropriate if you already use jQuery. If you don't have or want jQuery, you can use XmlHttpRequest to send SOAP or REST requests. If those are somehow inappropriate, use something else.
Our web services are distributed across different servers for various reasons (such as decreasing latency to the client), and they're not always all up-to-date. Rather than throwing an exception when a method doesn't exist because the particular web service is too old, it would be nicer if we could have the client check if the service responds to a given method before calling it, and otherwise disable the feature (or work around it).
Is there a way to do that?
Get the WSDL (append ?wsdl to the URL) - you can parse that any way you like.
Unit test the web service to ensure its signatures don't break. When you write code that breaks the method signature, you'll know and can adjust the other applications accordingly.
Or just don't break the web services and publish them in a way that enable syou to version them. As in http://services.domain.com/MyService/V1.1/Service.asmx (for .NET) so that way your applications that use v1.1 won't break when you publish v1.2 and make breaking changes.
I would also check out using an internal UDDI server if it's really that big of a hasle to manage your web services. Using the Green Pages of UDDI will tell you what you want to know about the service.
When you are making a SOAP request you are just sending an HTTP request to a server. If the server understands it, it will respond with an HTTP 200 and some XML back, if it doesn't it will send you some error HTTP code (404, 500, ...)
There is no general way to ask for the existance of a "method" exposed by a web service. Try to use the WSDL exposed if it is automatic, or just try to use the "method" and check for an error in the response (you don't have to send an exception to the user...)
Also, I don't know if I understood you well, but you are thinking of quering the server twice, once to check if the method exists, and second to make the actual call it if it does? I would just check for the error if it doesn't, and proceed normally if it does.