So right now our company has custom SOAP web services that hold functions to do things (e.g. sending emails, getting employee info, etc.) and are connected via Service References.
We want to make the switch to Web API 2, but I'm kind of lost on how we can (or if it's possible) to do that since all of our services interact with SOAP.
I wanted to create brand new Web APIs for each service we have which would hold the methods, but I'm not sure where to start. I've scoured the internet, but I haven't really found anything that answers my question.
Can someone shed some light on this for me? Thanks
well, you can create the Web API Service, and exposes the functions that you need, maybe, this service can be accessed from anywhere, but, the real functionality is on the soap (that can be in a DMZ for example), so, create a class library that consume those services and Web API now use this class library, so Web API will be only a facade.
But, first think, is really necessary have this facade in web api to consume those services?
Remember that if your soap services are built with WCF, WCF has support for HTTP protocol.
Related
I'm new to the concept of REST. And so far I've used a REST client (Advanced REST client) to make all the requests. But I don't understand the point of it all if I have to use a REST client to access the web service. I mean how then is a layman supposed to access a web service in his browser? And can browsers at all access access web services? If yes then why do I need a REST client?
The layman access a REST service all the time, when they access a web site (though many web sites violate REST principles to varying degrees). The REST architectural style was arrived at by examining why HTTP worked well, and was then used the conclusions to influence how HTTP 1.1 improved on 1.0.
They aren't expected to access a REST web-service, because a web-service is a service which uses the properties used by websites to provide machine-readable rather than human-readable data. A RESTful web-service tries to do this by taking advantages of how HTTP works and working with that. (The earliest "web services" seemingly started with the assumption that the web was a failure and needed to be coerced into working with the sort of RPC model that had been used previously, despite the fact that if this was true there'd be no advantage in using the web rather than the existing RPC protocols).
The layman therefore would more likely use an application that in turn used web services (whether that application was a web application, desktop, mobile, or whatever). The layman uses them the same way that they use any programming techniques; they use something devs built using them.
And can browsers at all access access web services?
Often they can get at least read-only access and sometimes a bit more. When this is the case it can be extremely useful for debugging.
I've been reading around trying to understand what RESTful API is all about. I guess I understood the general outlines and a bit about how it's related to HTTP and all that.
In fact, one of the jobs I recently applied for required a 'must' knowledge of a RESTful API!! The job description was messy anyway and seemed it had been written by an HR person, or somebody who didn't actually have an advanced technical knowledge.
I fail to see how, as a frontend developer / UI/UX designer, I could benefit from the vague RESTful API stuff? What's the connection?! Should really be bothered?
Thanks!
Simple and Precisely NO.
For only a front End Developer; it is not necessary, it is must (or SOAP bases API) for BackEnd Application Developer.
I am Android app Developer, made REST api for my app and my friend is just working on Web Page UI for that APP.!
Ajax calls are little to know for you.!
But one should know little bit about APIs, it never hurts :)
RESTful api, and web services in general, are a way to abstract back ends from front end developpers. It allows front-end developpers to do their interfaces without the need to code any server-side logic.
Web services contain all the business logic. As a front-end developper, you'd need to know how to interact with such services, but the whereabouts of the api call are not required of you to understand.
Finally, it's a way to define clear separation between what the application looks like and what the application does.
REST is a way to think applications. To make short, the client is stateless and you use HTTP methods for what they are designed to in order to interact with your server resources. You also leverage HTTP status codes, media types, content negotiation (Conneg).
If you want to know more about principles of RESTful services and Web API, you could have a look at this link: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
Hope it helps you,
Thierry
From client perspective the two main differences between REST and other e.g. SOAP webservices, that you have to use stateless communication (so you won't have a server side session, login, logout, etc...) and you have to use hyperlinks as request templates instead of building request from scratch. Because of these constraints your client breaks much harder by API changes.
I want to implement REST service in gwt .But I don't know how to go about it. I read some documents where they have implemented it using RestyGwt and jercy. But I have one app which is deployed on tomcat. Then situation is that my client side app is calling the methods on the application present on tomcat.
I have to implement it using REST so that my client side call will first go to Proxy service on client then it make REST call to the application on tomcat and fetch result and return. How can I do this in gwt. ?
As mentioned, you can only communicate with REST service.
Anyway, maybe take a look on dispatch concept in GWTPlatform and their way of implementing it. (https://github.com/ArcBees/GWTP/wiki/Rest-Dispatch).
Idea is easy, you have an action on client side which is registered to deal with rest url. You can define action interface with some additional annotations to tell what is excepected to be send and received. They are using piriti library for json serialization.
It is up to you if you need only client side implementation or you would like to use server side service creation too.
You can NOT implement a REST service in gwt, since gwt is thought as a client-side solution.
What the GWT kit provides for server side are a few utilities to facilitate the comunication between client-side and server-side when both are written in java (RPC, RF).
So you can consume a REST service from gwt (RequestBuilder, gwtquery-ajax, etc), but if you want to provide REST services you need a 3party solution for your server side like Jersey, CXF, etc.
There are, though, 3party solutions which provides the server side and client simultaneously like restygwt, errai-jax, etc.
If you are looking for a simple and reliable solution to query rest services from the client, in this question you have a client implementation done with gwtquery (ajax, databinding, promises)
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.
I want to use a WCF service and consume it using all the mobile platforms iPhone, android, Blackbery, Nokia etc'
Whats my best strategy for using those clients with a WCF service. it will have to be secured of course.
Thanks
amit
I disagree with SOAP and JSON. Use RESTfull service with POX (plain old xml). It will be most probably supported by all platform. Mobile phones can have limited SOAP stack implementations and JSON is usually used with browsers. My friend has BlackBerry and he continuously complains about its support for JavaScript.
To secure your service use HTTPS.
Use a SOAP or JSON endpoint. Most platforms will have support for these (or it'll be easy to find libraries). JSON is more web oriented (Javascript) but will work in other situations as well.
Mono supports WCF so maybe their iPhone and Android will support it as well.
Totally agree with #Ladislav on not expecting clients to be able to consume SOAP. Seems like SOAP stacks are lacking unless your client is native .NET or Java. Your clients will thank you by allowing them to choose JSON (web clients) or XML (system integration). Secure via HTTPS and basic auth or an API key.
If you already have an existing infrastructure of WCF services that you want to aggregate, or adapt, for downlevel clients you could put that POX (or 'REST') service in front of them and let it handle mapping protocols and formats for you. e.g. HTTP/S to TCP/IP and XML or JSON to SOAP.
The upside is that you will make it easier for downlevel clients to consume your services. The downside is that you've added an extra layer, which will cause complexity. Some tools, like WCF Routing Service (free) or Apigee (commercial), coupled with a solid automated deployment proces can help mitigate this complexity.
To build a REST service that supports XML or JSON, create your service with this template, it's designed for .NET 4.0. From there you can configure endpoints that respond in XML or JSON and let your client tell the service what response type it wants.
EDIT You can also have the service respond in a default format to reduce every client having to specify what format.
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="" defaultOutgoingResponseFormat="Json"/>
</webHttpEndpoint>
</standardEndpoints>