I thought to practice SOAP API. I know it is a time for REST but I thought to give a try to SOAP. I somehow got Flickr.com API supporting SOAP but it has very difficult documentation. No, working examples are available.
Q1. So, do anyone know where I can learn SOAP. Do anyone has SOAP working example for Flickr API
Q2. Any service other than Flickr providing SOAP interface. I saw Google search api has closed new request for SOAP.
regards
SOAP has been largely superseded by REST on the public Internet - as you have noted in your question and has been alluded to in comments.
There are still large users in the Intranet context, companies with an installed base of SOAP, Service Bus, and other concepts that you may well come across if you end up working at one of them. (There are still CORBA users out there also!) When you control both ends of the application, you may have less reason to be flexible using REST.
So if you are looking for useful public implementations you are mostly out of luck.
That said: do create your own services and try them out on your own. Define a service and implement it. Create a client in a different language. Create another client in a third language.
If you are looking for an educational experience, this will lead you down some of the same paths that has lead to REST use in wide-scale disparate systems (and may also shed light on why the public/private has split the way it has)
Good Luck
Related
My client suggests that implementing a web service using WS-Policy entries inside the WSDL (using WS-SecurityPolicy standard, which seems to be the recommended way) might cause incompatibility issues with clients that call the web service. My first question is, are his concerns correct? If not, how can I prove to my client that it is safe to use WS? I could not find anything on the subject.
If compatibility issues can indeed occur, I need to find a different way to implement WS-Security requirements (like signing parts etc.) without Spring, using JavaEE APIs. I could not find anything on that subject either. The only thing I could find is about standalone web services but I do not want that, I want a web application and I need to use JavaEE APIs (so no Spring).
Any help will be appreciated.
If you have pre-existing clients already using this webservice, then yes it will break compatibility if you add WS-Security.
But if no one is using it, or it hasn't been developed yet, how will this cause compatibility issues?
Personally I see WS-Security as rather complex, particular in the area of signing and encryption, so if your client had said that some clients might not have the skills to implement the web service I would have been inclined to agree with him.
may I have some example/typical use case of HATEOAS? I agree it can be a very powerful concept provide great flexibility but I am not sure how to properly get benefit from HATEOAS. would be great if you can share your experience/use case.
A good answer from #dreamer above, but HATEOAS is not present in most REST-based services. It is a constraint on the REST architecture style that allows clients to interact with a service entirely via the hypermedia contained in the resources.
If you look at the Twitter or Facebook REST APIs, you won't find hypermedia. Look at the Facebook friendlist resource. There are no hypertext links in that resource that you can use to transition the state of the resource - to delete, update, etc. Instead, you need to read the out-of-band documentation to understand what you need to do to delete that resource.
One of the claimed advantages of using hypermedia in your APIs is that you can manage change within the resources themselves. For example, what if Facebook wanted to add additional functionality to the frendlist? If it were built with HATEOAS in mind, the resource would be updated to add the hyperlinks provides those additional state transitions.
If this sounds difficult, you're right. But as a developer of client applications, however, once you understand how the hypermedia is presented, you can build applications that will evolve along with the API itself.
So how do you build APIs using HATEOAS? A number of options are out there, but I like the Hypertext Application Language (HAL) the best.
UPDATE: Since you asked for an example, here's a link to a demo using HAL.
Good public HATEOAS use cases are hard to find, because there are a lot of misconceptions around REST, and HATEOAS can be hard to implement. You really need to have a good understanding of its benefits, before you're willing to put yourself through the trouble of getting it to work, and if the clients don't follow it correctly, all work will be in vain.
From my experience, implementing proper REST in a company is a culture change as important as moving to version control systems or agile development. Unless everyone adopts it and understands it, it causes more trouble than it solves.
Having that in mind, I think the best example one will find is the foxycart.com HAL API, on the link below:
https://api-sandbox.foxycart.com/hal-browser/hal_browser.html#/
It's very powerful concept used in RESTful presentation of the application to the client. There are many many projects which are adopting this interface now. A typical use case for this is Web Services APIs using RESTful APIs. A RESTful APIs typically consists of the following elements:
base URI, such as http://example.com/resources/
an Internet media type for the data. This is often JSON but can be any other valid Internet media type (e.g. XML, Atom, microformats, images, etc.)
standard HTTP methods (e.g., GET, PUT, POST, or DELETE)
hypertext links to reference state
hypertext links to reference related resources
The application state can be modified using above HTTP methods for example, to get a particular resource, A client can issue a REST query using curl like:
curl -X GET --url "http://example.com/resource/" -X "Content-Type:application/json"
you could go through the man pages for curl and its usage. More on RESTful interface concepts can be looked upon at wiki
This might be a silly question on this site, but I want to learn more about it.
Being in the Software Engineering field, I have come to know that it's useful to get acquainted with Web-Services. I am trying to understand it. To do so, I must know the difference between a Web-Service and a Application-Service in simple terms.
I have heard about SOAP & REST Services.
For a newbie like me, its overwhelming to understand these concepts when I search them in Google.
How to understand these things better and in what order?
I think it's a great and simple question which usually confuses most of developers. What is Application Service and what is web Service?
Web service is a common term which you can find easily on the internet. Although some time they cross each others boundaries but here is a simplest explanation I can think of:
Application service or Application Layer is an abstraction layer reserved for communications protocols and methods designed for process-to-process communications. Application layer protocols use the underlying transport layer protocols to establish host-to-host connections.
Some time you can also use Application Service to define method calls within your application.
WebService: Any application or method which can be accessed by web is a Webservice. You can also say: anything available on the web is WebService.
There are three common web service architectures:
RESTful resource-oriented,
RPC-style e.g. SOAP
REST-RPC hybrid. 90% of the web sites use this unknowingly e.g. http://mysite.com/get/pictures?tag=birthday :)
I'm designing a set of web services to allow our clients to connect from their apps to one of our systems. Our clients have their apps developed in all varieties of frameworks (.NET, Java, PHP, Python and even the occasional all JS app), so obviously WS is the way to go.
Investigating a little about truly interop WS I've found that the way to go is to design first the WSDL and XSD and derive the implementations from there.
What i'm really looking for is guidance if this is really the way to go. I've read that WCF creates interoperable WS but i'm not a fan of MS creating something standard.
Should i use WCF or there is a good set of tools for designing WSDL and XSD without the pain i'm expecting.
Thanks in advance
If you want to interoperate with JavaScript, then best to make more of a REST style API. This is basically just standard HTTP calls, so you're interopable from the get-go. However, you've kindof indicated that you want to use SOAP, so ...
If you're going with SOAP/WSDL, I'd definitely advocate using the server platform - yes, even .NET - to generate the WSDL, then simply check that the options you're using are producing a good, interopable WSDL.
I'm a Java developer with a history of PHP & Perl, and I've interoperated with .Net on a number of WS projects, from both sides of the coin (as server and client). There's usually no major problems - just be wary of a couple of things:
certain proprietary elements that MS
mixes in with the open standards. For
example, they may offer NTLM-style
authentication, which really isn't
needed in most use cases,
particularly when you're using SSL
certificates.
SOAP has taken a few
different forms over the years
(Document/Literal, RPC/Encoded, ...)
you'll probably find you don't need
to worry about this, as RPC/Encoded
died along with old frameworks, and
most modern frameworks tend towards
Document/Literal
SOAP offers a few
bolt-on standards (e.g. MTOM & DIME
for attachments, and SOAP-WS for
authentication). Try to avoid those
bolt-ons, as different platforms
implement different subsets.
For security, I'd advise to use SSL for
the trust & confidentiality, and then
either HTTP basic auth, or simply custom
string tokens in your soap request definition.
Just keep the WSDL as minimal as possible, try interoperating quite early in the process, and you shouldn't have too many problems
You can use WCF and contract-first development.
If interoperability is the main concern then I would recommend using WCF to provide the service implementation but instead of relying on WCF to generate the service interface to use contract-first development to model the interface.
A really good article on how to develop this way is Schema-based Development with Windows Communication Foundation.
If you are going to roll your own WSDL and schemas you are probably going to want to get an editor like XmlSpy or LiquidXml. I like the price of LiquidXML (free!) but I can't recall if you have to pay for the web service features.
Another interesting tool for contract-first development with Visual Studio and WCF is WSCF.blue. I haven't used it but it does appear to be actively developed based on the WCSF.blue roadmap.
WSDL and XSD are language independent, you just have to have some mechanism to communicate using other languages. Good thing for you to do would be IMHO core data design, so you would not need so many XSD for the same data entities.
I'm not sure what you mean when you ask "should I use WCF"? WCF is the current mechanism for developing web services (and other kinds of communicating services) on .NET. There is no other current mechanism. The others are obsolete, or else considered "legacy technology".
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.