I'm Looking for Web Service develop(by delphi) tutorials, including the development of services and clients. Thanks!
It isn't free, but Bob Swart just published some updated courseware for Delphi 2010, which includes one specifically for web services.
I understand that his courseware includes updates, support, follow-up questions, etc.
Related
I have searched a lot upon internet but still i didn't get the clear difference between web services and web APIs? Somewhere I read that all web services are API's but all API' are not web services. How?
What all I know is both allow to utilize the functionality of other applications.Can someone describe me clear difference?
I have been on the same journey to learn the differnce between Web API (not JUST API) vs Web Services.
First, we know for a fact that both use the Web as the communication tool as stated by #Kris.
While looking at these 2 videos, both serve as the "middleman" (the waiter in the restaurant) for a client to ask a Web Server to process and deliver a response.
Web Service (From 0:35)
API (In general) (From 1:12)
When I was looking for an actual differnce between the two, usually most articles and videos go on an unrelated comparison between "Web Services vs API" as they exclude the "Web" out of "Web API".
See this article, for example, which contains the title "Web API Vs Web Service...." yet, contain sub-titles like:
"Differences of API vs Web Service"
"Pros and Cons of Web Services vs API Service"
"Web Service vs API: Fueling Both With Scraping Robot’s API"
The only difference I could find is if we were to discuss this in .NET context.
Here's a question post related to this.
To sum it up, Web Services are used in the SOAP protocal while Web API is usually created in the RESTful way. The more detailed answers are in the post but ultimatelly do not answer the main question that is asked.
Conclusion: The question raised in the public domanin has no clear definition to what is difference between the two, thus the 2 terms are ,for the most part,
interchangeable
All web services are APIs. An API is an Application Programming Interface. But there are offline APIs, which are not web services. There are APIs for all things from Office to Websites. The API is just a defined interface to be able to control/communicate with some software. Web Services just provide that means of connecting over the web.
There is more to discuss when you are talking about APIs which are communication protocols and data formats, but you get the basic idea.
An API (Application Program Interface) is the interface through which another program can communicate with a program.
A web service in this context is one of those programs with an API. 'Web' means that it is accessible via the web, mostly via HTTP. A service usually has a well defined purpose.
For instance a date web service's purpose could be to provide the current date. The API of my service would have a single 'endpoint': get the date. The service then implements this API. It somehow retrieves the date and sends it back.
When I used to create xml web services before, Visual Studio created a SOAP interface where any HTTP/XML based client could consume it. From what I heard from a colleague, Microsoft moved away from this standard and created their own standard. At this point, I am leaning toward writing an asmx web service application (because of the ramp up time to learn WCF) and was wondering if other platform applications (java or other based) will be able to consume them.
Any light you could shed on this for me would be appreciated.
EDIT: For clarification, I am using ASMX web services, and not WCF.
Depending on you WCF endpoint binding (wsHttpContextBinding, for instance), you can keep that SOAP format to exchange messages with .NET services. No "new standards" were created this time. =)
You can check this article for more information about WCF Interoperability
It's my understanding SharePoint 2010 has introduced a new JavaScript API, a brand new assembly for Silverlight clients, but does anybody know if there will be still support for good old Web Service Access?
By old services, I am referring to the old interface
http://msdn.microsoft.com/en-us/library/dd878586.aspx
Yes SharePoint 2010 still has web services. Review this MSDN section for more information.
Essentially the new API's are there to help client side code run interesting code without having to use the Web Services. If you have ever tried utilising a webservice from Javascript you can understand the pain the new API's are trying to prevent.
The Web services are still supported. However, the data-retrieval oriented Web services should be considered semi-deprecated. Going forward, you shoul use either the client object model or ADO.NET Data Services to get data from a client.
I've been trying to figure out how to administrate the whole thing with whatever APIs are available. The MSDN documentation seems like what I need, except I feel stupid and can't find where those APIs are on my server. There are no URLs to be seen in the documentation. Am I blind?
I ask this question in anticipation as part of a project. I have experience of developing and consuming web services in the past and am au fait with those. However I have been told that as part of this next project I will need to use "secure" web services. Can you provide some insight into what additional development tasks there will be to implement these as opposed to standard dare i say it insecure web services?
Cheers
Unless you have a complex multi-hop scenario, then SSL is vastly more practical and interoperable than anything based on WS-Security or related specification
If your going to be using WCF, check out these guide lines on MSDN
Exising ASMX Web Service can be secured using Web Services Enhancements (WSE) 3.0
I'm going to be developing a REST-ful Web Service for a new public website. The idea behind the web service is to have 3rd parties develop fully functional UIs for the business logic.
For security reasons, I'd like to avoid users having to give their passwords for our service to the 3rd party applications. (Perhaps this shouldn't be a big concern?) Instead, I'm looking to implement some sort of login system on our site that provides an auth token to the 3rd party app but keeps the actual password out of their hands.
This made me think that OpenID might be a potential solution here. It seems to me that it should work: the actual password is handled by the OpenID provider and so it doesn't rest with the 3rd party app. I think that the trouble would probably lie with the various passthroughs, but that should be manageable.
However, there's a surprising lack of Googleable info on this, so I'd like SO's opinion. Has anyone implemented a similar system before? Is it even possible? Is it worth the trouble?
I agree completely that what you want is OAuth; I say that having worked on both OAuth and OpenID systems. I've also been in your boat a few times, having to develop a REST web service api.
For a really good ideas on OAuth, and why it is what you want see these attached article:
These are must read, there are four parts read them all:
http://hueniverse.com/oauth/guide/
the RFC, read after reading above as it can be a little daunting for most:
http://oauth.net/core/1.0
And then finally maybe some code. I have a couple projects hosted that are using Java/Groovy to do OAuth. One is a plain old OAuth client, the other is a client for specific interactions with NetFlix.
http://www.blueleftistconstructor.com/projects/
If you are relatively inexperienced with REST (you haven't built a full scale web api yet) I would recommend that you buy (or better get your boss to) "RESTful Web Services" by Richardson & Ruby. It is an O'Reilly book. I can say that it is one of their better books to debut in the past few years.
It might also help to look at some RESTful OAuth based APIs. The NetFlix API is a perfect example: http://developer.netflix.com/docs
Good luck and happy coding!
So far, I've found 1 worthwhile link:
http://markmail.org/message/utf7js473zqv45hv
This conversation mentions something called "OpenID Exchange" which is right up my alley... but the included link is broken and there's not much solid information on Google for it.
Looks like OAuth might be the ticket: http://oauth.net/
We have been working on a project to integrate OpenID Authentication for SOAP web services. You can find our project at http://code.google.com/p/ws-sandhana/.
You can provide Single Sing On to your web services using OpenID authentication and you can enforce the trusted OpenID Providers and required attributes of the users by defining service security policies.
This is an open source implementation on Apache Rampart which is the security module for Apache Axis2 web service engine. You can find our blog at http://sandhana-project.blogspot.com/ for more information.