I'm thinking of starting with XML, JSON, and DSON (because why not?). Are there other formats that are or should be used?
If you intend to include hypermedia in your responses then I recommend using one of Mason, HAL, Sirene, Hydra (JSON-LD), Collection+JSON or UBER (all depending on your preferences).
Related
I've never really heard of HAL until I started working on a new project that is making use of it. From what I can tell, it's basically a way to easily follow links to traverse your way around a restful API's structure.
So if I understand this correctly, both tools are to make it easier to traverse around an API's documentation to see all the different means of communicating with said API. Essentially both of these are tools used for documentation purposes only?
REST APIs must be hypertext driven. It's not merely for documentation purposes, but for driving all interaction with the API. If you're not driving the interaction through links and clients are building URIs from templates in documentation, it's not RESTful. The authors of Django-REST-Framework themselves recognize the name is inadequate.
http://www.django-rest-framework.org/topics/rest-hypermedia-hateoas/
You should read the links provided in that document, specially this one:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
With that in mind, your REST API has to use a data format where links are standardized so clients know how to parse them. This would constrain most APIs to use HTML or XML, but since JSON is such a popular data-exchange format, there are some efforts into designing conventions for adding hypermedia-awareness to any format, like HAL.
Django-REST-Framework supports hyperlinks in the HTML output, but -- AFAIK -- it has no support for hyperlinks in other formats. You can use HAL-JSON if you want, but you'll have to implement support for it.
while going through the differences between SOAP and REST there was onepoint that
SOAP is a XML-based message protocol, while REST is an architectural style
what I am not able to understand is that what does it mean by REST is an architectural style???
Please help on this.
THanks,
Vineet
This is actually quite a common issue, one that I had to face my self as well.
There are two Web Services architecture structures: Representational state transfer (REST) and Remote Procedure Call (RPC). The wikipedia definition of archtecure structure is:
"The term software architecture intuitively denotes the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations."
Its hard to further define what it means. You either get it or you don't.
The basic difference between them is that REST uses already available technologies that the web is built on, while RPC adds additional layer of abstraction to define communication. In general REST are simple, lightweight WS but without formal communication specification, while RPC is heavy, bit more complex but with formal communication specification.
Now, for examples of implementations (which are basically communication protocols) of those architectures:
RESTful - obviously uses REST architecture
SOAP - uses RPC architecture
Because it is based on two architectural styles
1. Layered, code-on-demand, client-cached-stateless server (itself a composition)
2. Uniform interface
The term software architecture denotes the set of practices used to select, define or design
In REST there is much more flexibility in choosing the mode of data transfer and also the way we implement it unlike SOAP where the data has to be sent in XML format only.
If we are using RESTful the mode of transfer of data can be JSON, XML, Simple Text etc.
I've been looking at the resources definition of the Change Management module of the OSLC. Why using RDF?
Is this use related to semantic Web services?
Thanks
Put simply because RDF is portable, inter-operable and reusable
Using RDF means the data in your system is intrinsically reusable even by applications which know nothing of your specific data model (i.e. vocabularies and ontologies etc) since they can still process the data and extract information from it.
Also using RDF means you don't tie yourself to a proprietary/application-specific format or to a specific XML schema and you can easily extend your data model or add annotations which are ignored by the main application as you see fit.
Expanding on the OSLC concept —
OSLC aims provide common means of integrating resources through a common architecture using discovery, linked data, and common resource formats.
There are community topics on alignment to the W3c linked data and semantic web.
You can find out more here : http://open-services.net
A good introduction can be found here: http://open-services.net/html/case4oslc.pdf
I have been playing around with Apache CXF, in particular the various data bindings it supports: JAXB (the default), MTOM, Aegis and XMLBeans. Since all of these are supported, I suppose each has its merits. I came up with these:
Obviously, MTOM is to be preferred where large attachments are involved.
JAXB depends on annotations, so it is less suited when modification of classes is restricted.
Aegis has no wsdl2java tool, so it is less suited for "contract-first" development, i.e. start with a WSDL and generate your Java code from that.
It appears that Aegis provides slightly more control over the mapping between Java classes and XML through its declarative syntax in Class.aegis.xml files. On the other hand, I couldn't devise of any scenarios where JAXB did not do the trick.
I found this question juxtaposing JAXB and XMLBeans, but it doesn't give a comprehensive overview:
JAXB vs Apache XMLBeans
Besides these naive, a priori considerations, do you have any blood-and-guts experiences that would support the use of any other binding besides JAXB? I'm asking from a CXF point of view, but if any other options come to mind (e.g. Castor) please don't hesitate to elaborate.
If starting from scratch to create a WSDL first web service, then I definitely would recommend sticking with JAXB 95% of the time (maybe even higher). It's definitely the best tested databinding in CXF and performs quite well.
Where the other databindings come in are usually for one of two cases:
1) Java first use cases where you have something already written in Java that you want to expose as a web service with little to no modifications to the code. Aegis has it's strengths here as it's designed to be able to handle a wider range of things than JAXB. However, if you CAN modify the code, adding JAXB annotations usually isn't that hard. If you have mostly normal "beans", it's not a big deal.
2) Existing applications that use a particular mapping. If you have exising applications that are expecting XMLBeans beans (or SDO beans if using 2.3-SNAPSHOT of CXF, or JiBX beans if following the GSoC project), then using the other databindings could help by removing any needed mappings from JAXB to those object models.
Hope that helps a little.
Remember that JAXB is a specification so there are multiple implementations: Metro (Reference Implementation, MOXy (I'm the tech lead), etc.
JAXB can be used starting from Java classes or XML schema. If you have classes that cannot be modified individual JAXB implmentations offer extensions to handle that. See MOXy's externalizable metadata:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/EclipseLink-OXM.XML
JAXB was designed to work with MTOM attachments see the attachment marshaller/unmarshaller.
MOXy has XPath based mappings which offers full control of your object-to-XML binding see:
http://bdoughan.blogspot.com/2010/07/xpath-based-mapping.html
parse google geocode with xstream
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/