The AllegroGraph RDF Store provides multiple channels to communicate through. I am developing a Web Service for that. I have the following questions:
How to implement a Web Service over this SPARQL Endpoint?
What are the best practices? CXF or Axis?
The link you provided points to the AllegroGraph API documentation. The documentation says:
The protocol described here is compatible (is a super-set of) with the Sesame 2.0 HTTP protocol and the W3C SPARQL protocol (SPARQL endpoint).
I think you may want to develop a small library that sits between AllegroGraph and the client applications and 'speaks' this protocol, which appears to be a combination of "normal" REST and SPARQL. A client application can then pass the arguments to your library, which translates them to arguments in a SPARQL query or normal REST request.
For these operations, you may be able to use one of the tools mentioned in this answer, or use an SPARQL API like Jena ARQ and a general REST API like JAX-RS, or similar functions in programming language of your project.
Depending on your project, you can integrate these functions (SPARQL and REST calls) with the client application. You could of course provide the services again as a web service (using e.g. CXF or Axis), but if you control the client application(s) this may be too much for your project.
Related
We are using SOAP based web services to let end user schedule service appointments. Our portal is WebService client & we have a number of Vendors(who are spread across the globe in various timezones) who are building Webservice Server operations.
We are thinking to build it as a contract first SOAP based web services so that we have tight control(interface based e.g. date-time format should be standard xsd:dateTime etc.) over what can be sent & received as part of XML messages for possible success & error scenarios(via different error codes). We want to keep single client code for all the vendors. We would like to determine
1) Should we think about using RESTful web services?
2) Is there any way the vendors can use RESTful services also if they want at their end(by sticking to our WSDL contract) & we use SOAP at our end
First a little bit about,
REST (Representation State Transfer) is an architecture style to develop webservice. In which data and functionality are considered as a resource and can be accessed via URI (Uniform Resource Indicator). It follows client server architecture and uses stateless protocol (usually HTTP). Typically in REST webserivces resources are acted upon by GET, PUT, POST,DELETE operation. Generally we use JSON to exchange data between client and server. It is light weight.
On the other hand SOAP (Simple Object Access Protocol) is a XML based mesaage protocol. Which is generally used on enterprise level to define their own interfacing and operations as services. It also follows REST architecture.
So basically, it is a RESTful webservice.
Now to answer your question,
It seems you are going to expose your webservice client on enterprise level. Which is going to be used by many vendors to implement their own webservice server.
So, it is perfect, you go with SOAP webservices.
You will define the skeleton of the webservice like Message formats, Operations, binding etc which is called WSDL. It is widely used standard and very easy to understand by any third party. Something called WADL is used for REST services also but it is not very user friendly.
The same contract (WSDL) will be used by your vendors to implement the webservice on their server in Top to Bottom approach using some API, for example JAX-WS.
This way you will have a tighter control over your operations, formats, security etc. in a single contract (WSDL).
Now if a vendor wants to use REST webservice instead of SOAP. You can build a JAVA proxy on top of your client. Which will convert your soap messages into REST to send/receive request/response to REST webservices. But you can not dictate your contract in this approach. Although, You can recommend vendors to build their own proxy to handle your SOAP webservice requests. This way your contract will be intact.
If you are going to expose your webservice client for small applications then it is alright to go with REST but if you are an enterprise and going to expand in future, you should go with SOAP for robust features and easy maintenance.
Disclaimer: please do not consider this answer as really serious.
Well, I think question too abstract. Why do you asking it? Because you see yourself that currently everything is RESTful? Then you'r right. You can do any protocol. But if you will do REST with JSON instead of XML, everybody will thank you. And if you will use 40 years old technology for creating modern service, then probably not. Same for your contractors.
The only advantage SOAP seems to have in your situation is that it is already implemented.
SOAP is a complex standard with unfriendly implementation and verbose implementation - i.e. hard to work with and maintain. Also note that you are not even using it "by the book" since your security is external to it and not using ws-security
REST based interfaces would make your and your users' lives easier. I suggest you take a look at standards and tools like swagger for building APIs.If you're running on premise you can take a look at API gateways like tyk If you're running in the cloud you also take a look at AWS API Gateway
Does a RESTful web service (e.g. in a JAX-RS implementation) support both contract-first (top-down) approach and contract-last (bottom-up) approach?
Do RESTful web services support both contract-first and contract-last approaches?
It depends on what tools/frameworks you use.
What you are talking about applies to a SOAP web service and its accompanying WSDL.
A WSDL describes what a web service expects as input and what should a client expect as output. It defines the contract to be followed in order for both parties to communicate with each other. You can obtain the WSDL by doing contract-first or contract-last and you can later use this WSDL to generate code for a client stub or a service skeleton.
But doing REST isn't the same as doing SOAP. Processes that worked for SOAP (a protocol) can't necessarily be applied to REST (an architectural style) just because we are familiar with them.
Unlike SOAP that exposes methods and method signatures, REST exposes resources. An understanding of the media types used in the exchange of those resources is all a REST client needs in order to communicate with a REST web service. There is no need for a separate document to describe the resources.
Because of the HATEOAS principle, REST clients are more dynamic and can adapt to other services that communicate using the same media types. Exposing static service description documents would be limiting for a REST service.
Having said that, there are REST tools that do expose a description document, for example Jersey who exposes a WADL (contract-last). I'm sure you can use the published WADL to build client stubs and I don't see a reason why you couldn't write the WADL by hand (contract-first) and use it to generate stubs and skeletons. But as I said, that might not be the best solution for REST.
Here are some posts you might want to read to form an opinion if contract-last or contract-first approaches make sense in REST:
Does REST Need a Description Language?
Why the slow WADL uptake?
There are 2 types of web-services as I know. First one is custom xml formatted messages and the second one SOAP standard xml messages. What are the differences between them? Which one is better, what are pros and cons of each of that two approaches?
By "ordinary" I assume you mean RESTful services. This discussion would be a long one, so I'll try to give you some key points:
RESTful services are the most used flavor of Web Services. They are closely linked to the functionality and principles of HTTP and can be accessed as simple as a GET request (other operations are POST, DELETE and PUT). The core concept is the "resource" which is identified by an URI. Common formats for REST are XML and JSON. It's a pretty straightforward and easy to use technology, which is what makes it so widely available.
SOAP web services are based on XML, most of them adhering to the RPC-style of app design (calling remote methods on a server and getting a response), and use 3 main pillars:
WSDL - Web Service Description Language - used to describe a service in terms of available operations, parameters, etc.
SOAP - Simple Object Access Protocol - used to construct interaction messages between the entities involved (client, server).
UDDI - Universal Description, Discovery and Integration - used to classify and publish available web services to a repository and enable discovery by potential users.
SOAP Web Services tend to have high overhead and generally have very verbose messages, but may be good if you need to implement more complex functionality and interaction in your application.
Strictly speaking only the Soap services are webservices. They are based on the WS-* Specs standardisized by W3C and Oasis. Sometimes a also reffered as Webservice are so called POX-Endpoint (Plain old XML) or REST Endpoint, which allows you to simply get a raw XML via HTTP GET.
SOAP Services carry their schema in form of a wsdl endpoint (usualy append ?wsdl to the service endpoint), so there a lots of tools to create proxy objects and hide the complexity of the webservice call. With POX Services you need to know which schema to use from e.g. the documentation.
SOAP Services carry the payload inside the SOAP Envelope (an XML Schema with header and body with the payload in the body). Having a header independent from the payload allows to reroute the content, sign and encrypt, authenticate etc. without knowing the content. But you pay by additional overhead in the message itself.
POX on the other hand leaves all that to the webserver and relies usualy on HTTP for authentification and compression. Encription and signing had to be done by your system. It is low overhead but also low discoverability.
Whats works best for you depends a lot on your scenario. If you work in a .Net or Java World, you often find it simplest to create a proxy and use that to work with the webservices as remote objects. You get a well build infrastructure and a comfortable programming experience. If youre environment does not support the proxy generation or if it had to be called from anything, POX might the very much more lightweight way to go.
"Web Service" refers to a more abstract and general concept. We can say that anything that can be served on web is a Web Service. SOAP Web Services or RESTful services are special kind of Web Services which has wide acceptance and has their own standards. While SOAP services are built on a new XML based standard, RESTful approach makes use of existing HTTP methods, hence more widely accepted (to my experience).
I have a set of embedded devices that run software written in c++. The API to communicate the devices is simple: get/set/acquire parameters and signals.
I'd like to implement common web application to access all of the devices from a single point.
My idea was to add XML RPC interface to devices and then use ActiveResource to access devices from the web server. This combination doesn't seem to be used at all in practice.
I'm free to choose any protocol inside the devices. What are your recommendations?
If you're already considering XML RPC I'm assuming you have some sort of web server running on the device. I would probably choose a RESTful web service over XML RPC. If designed carefully you could have corresponding services on your Rails app.
For example:
http://somedevice/signals.json - gets all signals
http://yourrailsapp/somedevice/signals.json - gets somedevice's signals; you could use an id instead here if that makes more sense (http://yourrailsapp/devices/1/signals.json).
You probably won't find much XML RPC stuff in the Rails community. Rails itself really pushes you towards RESTful web services. Specifically a resource-oriented RESTful architecture. There are great books out there about it but it comes down to using http methods (get, put, post, delete) instead of passing parameters and then some intelligent URLS.
What is the difference between OData and REST-ful web services?
UPDATE Warning, this answer is extremely out of date now that OData V4 is available.
I wrote a post on the subject a while ago here.
As Franci said, OData is based on Atom Pub. However, they have layered some functionality on top and unfortunately have ignored some of the REST constraints in the process.
The querying capability of an OData service requires you to construct URIs based on information that is not available, or linked to in the response. It is what REST people call out-of-band information and introduces hidden coupling between the client and server.
The other coupling that is introduced is through the use of EDMX metadata to define the properties contained in the entry content. This metadata can be discovered at a fixed endpoint called $metadata. Again, the client needs to know this in advance, it cannot be discovered.
Unfortunately, Microsoft did not see fit to create media types to describe these key pieces of data, so any OData client has to make a bunch of assumptions about the service that it is talking to and the data it is receiving.
The OData protocol is built on top of the AtomPub protocol. The AtomPub protocol is one of the best examples of REST API design. So, in a sense you are right - the OData is just another REST API and each OData implementation is a REST-ful web service.
The difference is that OData is a specific protocol; REST is architecture style and design pattern.
REST is a generic design technique used to describe how a web service can be accessed. Using REST you can make http requests to get data. If you try it in your browser it would be just like going to a website except instead of returning a web page you would get back XML. Some services will also return data in JSON format which is easier to use with Javascript.
OData is a specific technology that exposes data through REST.
If you want to sum it up real quick, think of it as:
REST - design pattern
OData - enabling technology
In 2012 OData underwent standardization, so I'll just add an update here..
First the definitions:
REST - is an architecture of how to send messages over HTTP.
OData V4- is a specific implementation of REST, really defines the content of the messages in different formats (currently I think is AtomPub and JSON). ODataV4 follows rest principles.
For example, asp.net people will mostly use WebApi controller to serialize/deserialize objects into JSON and have javascript do something with it. The point of Odata is being able to query directly from the URL with
out-of-the-box options.
From the OData documentation:
The OData Protocol is an application-level protocol for interacting with data via RESTful web services.
...
The OData Protocol is different from other REST-based web service approaches in that it provides a uniform way to describe both the data and the data model.
OData (Open Data Protocol) is an OASIS standard that defines the best
practice for building and consuming RESTful APIs. OData helps you
focus on your business logic while building RESTful APIs without
having to worry about the approaches to define request and response
headers, status codes, HTTP methods, URL conventions, media types,
payload formats and query options etc. OData also guides you about
tracking changes, defining functions/actions for reusable procedures
and sending asynchronous/batch requests etc. Additionally, OData
provides facility for extension to fulfil any custom needs of your
RESTful APIs.
OData RESTful APIs are easy to consume. The OData metadata, a
machine-readable description of the data model of the APIs, enables
the creation of powerful generic client proxies and tools. Some of
them can help you interact with OData even without knowing anything
about the protocol. The following 6 steps demonstrate 6 interesting
scenarios of OData consumption across different programming platforms.
But if you are a non-developer and would like to simply play with
OData, XOData is the best start for you.
for more details at http://www.odata.org/
ODATA is a special kind of REST where we can query data uniformly from URL.
REST stands for REpresentational State Transfer which is a resource based architectural style. Resource based means that data and functionalities are considered as resources.
OData is a web based protocol that defines a set of best practices for building and consuming RESTful web services. OData is a way to create RESTful web services thus an implementation of REST.