Simple task like make AJAX request , pass one parameter and return result, can be done with Web Service and IHttpHandler, so where is the difference ?
ASP.NET web services are in fact a type of HttpHandler that provide an XML based communication infrastructure based on W3C standards (SOAP/WSDL). This means that non .NET clients can interoperate with ASP.NET web services. In your case where you're making a very simple single ajax request to return a simple result, ASP.NET/XML web services may be overkill.
It may be more beneficial/efficient to implement a simple custom HttpHandler rather than invoking all of the plumbing and overhead associated with ASP.NET web services. With a custom HttpHandler you can just send the parameter you need and return exactly the result you want to see without any of the supporting SOAP xml that would be created when using XML web services.
Related
I read some articles and i search many about differences between Rest WCF vs Web api but I just find difference between WCF vs Web api , I find some difference:
WCF Rest=>
a)It support HTTP GET and POST verbs by [WebGet] and [WebInvoke] attributes respectively.
b)To enable other HTTP verbs you have to do some configuration in IIS to accept request of that particular verb on .svc files.
c)Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified.
d)It support XML, JSON and ATOM data format.
and
WebApi=> a)Unlike WCF Rest service, it use the full featues of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
b)Responses are formatted by Web API’s MediaTypeFormatter into JSON, XML or whatever format you want to add as a MediaTypeFormatter.
I want know other differences between them, and when is it better to use WebApi and when Rest Wcf?
I would say, if you start a new project and you need to expose a REST web interface in .NET, Web API is the way to go because AFAIK, WCF is deprecated. I would only consider to use WCF Rest if you have to expose both, SOAP and REST web interfaces.
WCF is not the good choice for REST because it was not made for it, when they implemented it they did lots of bad hacks. you can see how they try to convert xml to josn here
WCF is NOT deprecated, so powerful, and no framework can be comparable to it yet. but it is not for REST.
I am new to Rest web service and while learning it a question strikes me,
In SOAP based web service, WSDL is act as a contract between client and service provider, so, Client will know how to interact with service provider by reading the WSDL file and create a client which is highly capable of interacting with service provider. To my understanding, in Rest web service we don't have WSDL so how a client will generate its stub automatically?
In REST, clients are not generated automatically, in general. There is something called WADL, which is sort of "WSDL for REST", but it's not a standard yet and may never become a standard. But in general, all REST clients need to be created without the use of metadata from the service.
I am working with a CRM System that provides two types of APIs: servlet API & REST API, both of which are over HTTP.
I used to integrate with REST API from my ASP.NET MVC web application by calling the REST URL and manipulating the returned JSON or XML. But I cannot figure out what is meant by a servlet API and can these APIs be called over the web from my ASP.NET MVC application or these APIs should be called inside a Java application?
Sorry if my question seems trivial to someone.
The Java Servlet API refers to a set of classes used to implement server side programs. The main player is the Servlet:
A servlet is a small Java program that runs within a Web server. Servlets receive and respond to requests from Web clients, usually across HTTP, the HyperText Transfer Protocol.
If you want a very simplistic analogy, the Servlet is Java's version of CGI (Common Gateway Interface).
A REST API is a way to build applications by fully using the architecture of the web. Leaving all details of REST aside and grossly simplifying, it's basically a HTTP API.
If you want to build a HTTP API, you can use Servlets. So you can also use servlets to build a REST API although there are better alternatives to that (e.g. JAX-RS) because servlets are a "low level" component and nothing shields you from all the boiler plate code you need to write.
You can of course call a Java application build on top of the Servlet API from other clients (e.g. from ASP.NET MVC). That's what it was built for. For this reason I don't really understand what exactly your CRM system means by a Servlet API and (a separate!?) REST API... so maybe ask the CRM provider?
EDIT : Based on what I've read about the ManageEngine Service deskPlus APIs, I'm thinking that this is just an unfortunate name chosen by the provider.
As I mentioned in my comments, when you say REST API you already provide some information from the beginning. Most people, when told about REST understand that you have some abstract resources, that these resources can have multiple representations (JSON, XML, whatever), that each resource is identified by a URI, that /customers is referring to a list of customers resources, that /customers/1 is a customer and that /customers/2 is another one, that you use GET /customers/1 to find out details about the customer and DELETE /customers/1 to delete it etc.
REST is one way to interact with an application, another one is to expose operations that can be called by clients, for example like what SOAP is doing. Before REST became the new kid in town people were doing stuff with SOAP. Unlike accessing resources, SOAP is focused on accessing operations. When you mention SOAP to someone she knows that it's a protocol that can use HTTP's POST to transmit messages around, that each message has an XML payload that contains the operation name to invoke and the parameters needed for the call etc.
But even before SOAP and REST becoming widely known, people realized that they can use a form submit to sneak in RPC calls through HTTP. The HTTP form based submission is one of the methods of the API in ManageEngine Service deskPlus. But the form based submission method (as far as I know) doesn't have a cool name like SOAP or REST... so maybe that's why it was named after the Servlet API?! (I'm once again emphasizing that this is just the server implementation which is not important in the context of the HTTP protocol).
So to conclude: Yes, you CAN call the ManageEngine Service deskPlus Servlet API from ASP.NET, even a web browser or any kind of HTTP capable client.
I am using Jersey/Tomcat6 for dveloping some web services. Compared to what I did for SOAP services, I am not getting the idea what should I share to my clients once the services are developed...just the URL of the web service ?? For SOAP, the WSDL file was enough, as the clients self-generated the stubs.
My service returns a list of User objects (with 2 Strings) in JSON format. How would my clients de-serialize the JSON if I share just the service URL with them ? Do I need to share the entity bean (The User class, and the list class) on my server side too ?
I have been reading about some WADL files for REST...are they helpful here ?
Thanks for any help !
It sounds like you probably want to put together an example client to give to your, er, clients to show them how to use the REST service. Ideally, of course, your REST service would fully support HATEOAS (Hypermedia As The Engine Of Application State), and so the means of traversing the resources to get the desired results would be discoverable; I've found that real HATEOAS implementation is rare, though. For a RESTful-ish service (one that doesn't fully support HATEOAS), example clients are useful. You can usually implement your example client in HTML with some Javascript; this makes everything very accessible for most REST client users.
With WCF, we can create services that can accept leverage HTTP POST and simple accept an XElement as it's parameter. I'd like to do something similar with a workflow service so that I can use jQuery to post an xml infoset to a service, have it run through a bunch of rules and then return an xml infoset.
With a WCF service, I can simply decorate the operation w/ WebInvoke and go on my merry way. Is it possible to use WebInvoke w/ a Workflow Service and if so, how should I go about?
Workflow services are currently tied to traditional WCF SOAP. You cannot use the WCF REST API (i.e., the WebHttp binding) with WF 4 currently.