okay this might be a pretty lame and basic question but its stuck in my head since i never had chance to work on web-services.
We can get the same "text bases" response(xml, json etc) from our server by very basic/simple implementations (lets say servlet) then why do someone has to develop a web-service.
What is the exception thing a web-service gives over simple http response?
At a basic level, you are quite correct, from a low level point of view, it's just text (XML) on a socket.
For simple web services, a servlet is adequate (I'm writing one of these as we speak).
When talking about something like SOAP and WSS-* web services, however, there is a lot of boiler plate processing and features available from the standards that web service toolkits expose as higher level transactions.
A simple example is data marshaling. If you treat it purely as XML, then your service basically gets to process the XML by hand -- parse it, evaluate it, populate your internal models, etc.
Contrast this to something like this from Java EE:
#WebService
public Person getPerson(String personId) {
Person p;
...
return p;
}
The web service stack will convert your Person object in to a SOAP compliant XML blob. It will also produce a WSDL that you can use to create client code (on many platforms: .NET, PHP, etc.) to make the web service code.
In the end, your client and server have only a few lines of code, while the frameworks do all of the grunt work parsing, marshaling, and publishing for you.
So, the value of the WS stack is that it handles much of the bureaucracy of writing WSS compliant web services.
It's no panacea, but for many modern implementations, SOAP <-> SOAP remote processing can be a, mostly, cross platform, drag and drop affair.
It depends. If your web service needs to answer a simple yes/no question like "does this username exist?", then return yes, no, 0, 1, etc may be enough. If you have one that returns all the faculty attributes, XML or JSON may be appropriate because of the structured nature. It's a little less prone to parsing errors than trying to parse plain text.
Related
I have to implement "service bindings" in a project in my school.
I just learned WSDL from w3schools.com. I came to know that "WSDL" is. I know WSDL but I didn't do anything with it. I want to go practical with it. I don't know how to do that.
From where to start? I know there are other things to learn and I don't know what are they.
I need some help in getting "practical". Its just in my mind I don't know how to implement it.
Based on your question I assume you are a little bit confused. You should talk to you teacher (or whoever gave you this assignment) and find what is expected for you to do.
Web services involve a lot of knowledge, WSDL is just one part of it.
As you probably have learned from w3schools, WSDL means Web Services Description Language. It is a way to document a web service's interface to the world.
A web service is accessible from an endpoint address, something like
http://some.server.com/context/bla/whatever
This tells you where to find the web service, it tells you nothing about how to call it (i.e. how are the messages going to be structured for a correct communication).
The WSDL provides you this info: what operations are exposed, how messages are composed, binding used etc.
So that you understand a bit how WSDL "fits" in the entire picture I'm going to use a little story.
Let's say some company wants to offer some online services. They expose these services as a SOAP web service and make it available at address http://some.server.com/context/bla/whatever.
After they advertise their services they have to actually tell their customer how to use the thing. They could send them an e-mail and tell them how to call it or they can write a Word document and tell them how to do it. But that is not practical, and a mail or word document can't be used to generate client code automatically. Some dude will have to write the code by hand... poor bastard.
This is where WSDL comes into play. It is a specification which describes the interface to the service. Beeing an XML file it is a human readable format but more importantly is a format that a machine can read and process and... as you probably guessed by now... can generate client code based on it.
As such, the company does not bother to write e-mails or documents. They document everything in a WSDL file and make that available online (the XML Schema types inside the WSDL... very important... you should read XML Schema).
To simplify things even more you can (usually) find the WSDL at the same address as the web service with just an extra parameter added:
http://some.server.com/context/bla/whatever?wsdl
Based on the WSDL the clients can now generate code that can call the service (in C# with svcutil.exe, in Java with Axis wsdl2code etc).
And Price Charming and Cinderella lived happily ever after... oh... wait.. that's another story :P.
Seriously now.... as I said at the beginning: Talk to you teacher and ask how you are supposed to get practical with WSDL.
Hope this explanation makes it a little bit clearer for you.
I am looking for GWT to C++ communication solution.
Currently I am trying to figure out how to run WSDL in GWT, but actually, have absolutely no experience in WSDL, and only little in GWT.
So, my question is about feasibility of working with WSDL in GWT (and how?) and other approaches would also be interesting if exist.
I am trying to avoid coding Java on the server and coding JavaScript on client.
GWT Side:
RequestBuilder and com.google.gwt.json.client.JSONObject for quick and really not that dirty marshaling api.
Overlay types require you to know your data configuration at compile time. With JSONObject (and it's JSONValue's), you can treat it like a slightly unwieldy key/value map.
Set your RequestBuilder to POST and serialize your payload by pushing it into a JSONObject and calling toJSON();
C++ side..
Find a favorite JSON library (may I suggest from the fine choices at http://www.json.org/)
(You'll have to build a method dispatching scheme, but if your app is simple, just use some simple if ()'s)
Send back a response with mime-type of text/javascript;charset=UTF-8.
Back in your GWT code, you read back the results using something like so:
if (Response.SC_OK == response.getStatusCode()) {
try {
String txtResponse = response.getText();
if (txtResponse != null && txtResponse.length() > 0) {
JSONObject result = (JSONObject)JSONParser.parse(testResponse);
//Do something useful...
}
} catch (......)
Now you can talk back and forth with no magic. (And goodness know, no WDSL!!!)
Thrift may be the best solution for you. A specific portage for GWT is available at : http://code.google.com/p/thrift-gwt/ .
You can expose a JSON-based API on your server and use GWT's RequestBuilder and JavaScript Overlay Types to consume it in the client.
You could also use an XML-based API, but JSON will be easiest because of overlay types.
I found Thrift is almost the only choice that includes code-generation-based data-binding solution with RPC support that works on C++ side (original Apache Thrift compiler) and GWT side (gwt-rpc-plus solution).
That is a coincidence, but Thrift is actually a good JSON data-binding solution.
The only problem I see with Thrift (and it's rather inconvenience) - it doesn't support structure polymorphism, which is Ok for JavaScript (Thrift supports it), but bad for real object-oriented languages like C++ and Java.
We are considering to develop a Flash front-end to a web application written using Django. The Flash front-end will send a simple "id" to the server and in response receive a couple of objects. The application will be open only to authenticated users.
To the extend of my current knowledge (which is basic for Flash) we can either use AMF or take an XML or JSON approach. AMF seems to have an upperhand as there are examples out on the internet showing it can cooperate easily with Django's authentication mechanism (most examples feature pyAMF). On the other hand, implementing a XML/JSON based solution may be easier and hassle free.
Guidance will be much appreciated.
We've used pyAMF + Django on many projects here, and it's a breeze to setup and get running. If you need speed, AMF3 is probably your best bet. It's the smallest/fastest way to transfer data, and serialization is taken care of for you.
On the flip side, setting up json with Django isn't much work either, and it would give you the ability to hook other, non-AMF systems into it without any extra work. You just sacrifice a little speed for that benefit.
If you think you'll ever need other systems working with the backend, or if you think you might switch to an HTML-only, or offer some kind of non-Flash version of your app, I'd go JSON, otherwise, I'd use AMF.
first of all, you should design your app in such a way this doesn't matter. the transport layer should be completely encapsulated, leaving the encoding format transparent to the rest of the app.
personally I prefer JSON to AMF because it's human readable (which makes debugging easier) and there are implementations for every platform/language (so you can reuse the server part with JavaScript for example). And I prefer JSON to XML because it's more compact and semantically less unambiguous as well as closer to common object models. Also it can transport numerical and boolean data in a typesafe manner.
JSON will probaby have the least complications and there's a great google code project that has JSON encoders and decoders here: http://code.google.com/p/as3corelib/
I have what seems to be a fairly simple question about implementing a data access client that strictly adheres to REST architectural principles. To start, let's assume I have a well-behaving REST API that I want to consume using a Django application. I'll start by discovering what services are available (edited for follow-up):
GET example.com/services/ HTTP/1.1
HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<services>
<service>
<name>Widgets</name>
<link>http://example.com/services/widgets/</link>
<item_link>http://example.com/services/widgets/{widget_id}/</item_link>
</service>
<service>
<name>Factories</name>
<link>http://example.com/services/factories/</link>
<item_link>http://example.com/services/factories/{factory_id}/</item_link>
</service>
...
</services>
Now, since I'm building a Django application based around consuming this API, how would I continue to keep exploring these services RESTfully? To adhere to REST principles, my application must be driven by the hypermedia received. I suppose the first step is easy enough -- interacting with a service by the name given. I set up a Django view as follows:
def get_service(request, service_name):
doc = etree.parse(urllib.urlopen('http://example.com/services/'))
uri = doc.xpath("service/name[.='%s']/following-sibling::*" % service_name)[0].text
...
From which I'll perform another request (edited for follow-up):
GET example.com/services/widgets/ HTTP/1.1
HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<widgets>
<item_link>http://example.com/services/widgets/{widget_id}/</item_link>
<widget>
<id>1</id>
<name>Whizbang Foobar</name>
<link>http://example.com/services/widgets/1</link>
</widget>
...
</widgets>
Now I'll display a simple list of widgets in a rendered Django template. From here though, how do I continue to interact with this service RESTfully? Perhaps I've befuddled myself into confusion, but the only reasonable things I can come up with are implementing a numerous amount of application views or a thin Django data model to persist the service URI.
My main concern boils down to that this is trivial to do without strictly adhering to REST architectural guidelines, but I feel like I've missed the boat completely in trying to do so. I understand designing proper REST APIs and clients isn't "easy", but it seems that I'm in dire need of a similar example to work through the actual implementation.
I apologize for the length and verbosity of the question and the inevitable facepalming of wizened readers.
Follow-up:
Is the following a valid way (using URI templates) of implementing these interactions? For demonstration purposes (in lieu of a more abstract implementation), another Django view to retrieve a resource collection item:
def get_item(request, service_name, item_id):
doc = etree.parse(urllib.urlopen('http://example.com/services/'))
uri = doc.xpath("service/name[.='%s']/following-sibling::item_link" % service_name)[0].text
...
Then the subsequent request:
GET example.com/services/widgets/1 HTTP/1.1
HTTP/1.1 200 OK
<?xml version="1.0" encoding="UTF-8"?>
<widget>
<id>1</id>
<name>Whizbang Foobar</name>
<tags>foo bar baz ham eggs</tags>
<index_link>http://example.com/services/widgets/</index_link>
</widget>
My main concern boils down to that this is trivial to do without strictly adhering to REST architectural guidelines, but I feel like I've missed the boat completely in trying to do so. I understand designing proper REST APIs and clients isn't "easy", but it seems that I'm in dire need of a similar example to work through the actual implementation.
The best example I've been able to find is the Sun Cloud API. Most of the documentation describes the various media types used by the system, which seems to be the key to pulling this kind of thing off.
I find that it helps to be writing your client at the same time you're developing your API. That way you can spot what's likely to make your API a pain to code for right away and fix the problem.
It isn't easy. If you follow the HATEOAS constraint to its logical conclusion, each media type you define will be handled by one of a family of clients. To the extent that you can make all of your resources follow a similar pattern of behavior, your job of writing clients will become easier.
For example, you could define a media type 'Index' that simply lists related resources. Index defines links for pagination, getting items in the list, finding items by name, etc.
Then, you might define a base media type called 'Item'. Item has a link for displaying its parent Index, updating/deleting itself, etc. Your resource Widget could then be represented by two different media types - one Index and one based on Item.
You could begin by implementing a single class that handles the Index media type. Then you could write a base class that handles all common Item media type behavior. Finally, you could write a Widget client that handles all widget-specific behavior and which extends the Item client. These clients could expose their functionality (availability of more links and data fields) in an idiomatic way for the language they're written in.
Processing a response from your server would then be a matter of matching the mime type of the response to one of the clients you've written.
In other words, even though the client for your service as a whole would be made up of many clients of limited scope, they would each be based on common behaviors and so could be implemented in a DRY way.
From my experience the REST model makes much more sense if the representations and their contained links are translated directly to a client UI. In this scenario it is the user that directs the exploring of the REST interface.
Often I see people trying to use REST interfaces as a kind of HTTP based data access layer. With this mental model, hyperlinked data provides little more than structural data relationships. It becomes difficult to build application behaviour on top of that interface without violating RESTful constraints.
I like to think of a RESTful interface as delivering UI content to an application that is going to render that content with some arbitrary technology. Unfortunately, REST is frequently compared to web services which, in my opinion, fit in a different architectural layer. Web services deliver data that is to be processed by a client application. RESTful interfaces should deliver content that will be rendered to the user.
Sure you can use a REST interface to deliver data to remote applications but think of it as simplified screen scraping.
When writing a client for REST interface I find it useful to imagine that I am writing a custom web browser that only understands the media-types that are delivered by that RESTful interface and is hard-coded to start at a specific URL and there is no address bar!
Sun Cloud API documentation is a great example of a RESTful API, focusing on the media types.
If I understand your question correctly, you want to explore an unknown service, correct?
If so, then you could, for example continue with an OPTIONS request to the "widget" resource, to see which HTTP methods it supports (these should be listed in the Allow header of the response).
You can then do the same for all URIs found in <link rel="whatever"> elements. If a resource found this way indicates that it supports GET, then fetch it and repeat ...
This way you should be able to explore all nested resources.
This kind of exploration will of course only get you so far, because to really interact with the service, you will need to know about its media types (or representations), and what the different <link rel="whatever"> actions you found actually mean. This step can't be automated, you'll have to read the documentation for the service and build you client accordingly. I suggest reading the article "How to GET a Cup of Coffee", which I think explains this interaction very well.
I know that some big players have embraced it and are actually exposing some of their services in APP compliant way, already. However, I haven't found many other (smaller) players in this field. Do you know any web application/service that uses APP as its public API protocol? What is your own take on AtomPub? Do you have any practical experiences using it? What are its limitations and drawbacks? Do you prefer AtomPub as your REST style or do you have some other favourite one? And why?
I know, these are many questions, not just one. The thing I'm interested here in is simple, though - how did the APP standard hit the market and particularly how does it seem with its adoption among web developers?
The company that I work for, is developing a lot of RESTful services.
However none of them expose public APIs.(In the sense that all services are internally consumed by our own clients). The reason why we went for REST architectural style was that we wanted our services to be easily consumable and more importantly scale well.
From my own practical experience I have come to the conclusion that HTTP + ATOM syndication format is a good idea, provided you want to keep things flexible(In terms of different content model, attaching and extending meta data associated with payloads, uniform parsing etc). ATOM ensures that everybody interprets the payload in an uniform manner without any scope for ambiguity.
However if one does not have any such complex requirements or does not forsee such requirements then the ATOM format could be a bit of an overhead. (For instance elements like Author,Title etc make sense more in the blogging/RSS world and may not make sense in your particular problem domain).
Also if the goal is to just serialize data structures at one end and reconstruct it at the other end, then most web frameworks(like WCF) have custom formats which are more appealing.
So in my opinion ATOM Pub is good if you need flexiblity in terms of data representation and if the playing field is huge with different kind of client.
However if you have a good knowledge of potential clients and server/client usage patterns then custom formats might be a good idea.
If the client is browser based then formats like JSON are very appealing.
Hope this answers your question.
My own research so far:
Wordpress supports AtomPub as its API protocol since version 2.3
GData is probably the biggest shot in the AtomPub field so far
Habari - new promising blogging system promotes APP as one of its main features
BlogSvc.net - an AtomPub
server, blog engine for .NET
platform, written in C#
Jangle - an open source project
designed to facilitate API access to
Library Systems
There's also mod_atom - an Apache module that stores entries in the filesystem.
Last time I checked (2007 or so) Atompub was fairly complex to implement. While you can whip together something that emits valid Atom feeds during the lunch break, implementing AtomPub was a fairly big undertaking.
That might have changed due to better libraries and tools but still it might be too complex to be implemented by smaller sides just because it's cool.
And the lack of killer AtomPub client applications puts little or no pressure on server operators to offer an AtomPub interface.