In my project there is a need to take two different SOAP APIs which can convert currency. I have searched almost everywhere and I could only find one API:
http://www.webservicex.net/CurrencyConvertor.asmx?WSDL
This works perfectly but I want one more SOAP API which has both request and response in XML format. I would be highly obliged if anyone can help me on this.
Related
We have a medium size app (100+ SQL tables), and we often need to integrate it with partner APIs (with our system as a client/consumer). Process of designing such integration is non-trivial:
We often need to map columns in our database to fields in requests to partner API.
Some fields in requests to partner API must be constant, or conditional
In rare occasions output from one API response becomes an input to another API request
There are many resources on the web to document REST APIs - there are specific formats for that (Swagger, RAML, etc.). These formats allow efficient generation of client code and human-readable documentation. However these formats are not very helpful for describing how your app integrates with an API. We create lengthy Microsoft Word documents which contain more or less a copy of partner API methods with comments how every individual field should be used. Such solution seems sub-optimal.
Googling for better options did not yield many results, namely Swaggerhub seems to have "comments" functionality which seems to target the problem above and pretty much that's all.
Question: are there some tools, formats, workflows, ideas, etc. which facilitate designing and documenting API integrations described above?
I dont know which language you use, but i work with ApiDoc
https://apidocjs.com/
He is perfect to generate an API REST doc with comment in NodeJS, he can be used with many language
I still don't know if google maps API uses the SOAP protocol or if it's a RESTful service. I've read its documentation but it doesn't say anything about that.
I know this is an old question but I wanted to try to give an answer anyway, because I do not agree with the logic in #Brick's answer (supports JSON and XML, therefore is RESTful).
There are quite a few different Google Maps APIs, so it is hard to answer your question without you specifying which one you mean. However, for an API to be RESTful, it has to comply with the following five or six constraints:
Client-Server
Stateless
Cacheable
Layered system
Code on demand (optional)
Uniform interface
So an API supporting JSON and XML might, or might not be, RESTful, depending if it complies with the constraints above.
I think Google Maps API is not a REST API.
Google maps API give us tools, methods and objects, when we include its API, We can use these methods to build a map, we need to give data to these objects in order to build our map.
So, we are not really asking for a REST resource, we don't use a REST client to access it and we don't get json or xml data.
A rest API works with standard HTTP methods (like GET, PUT, POST, and DELETE) and returns/add/edit/delete data from its resource.
REST does not enforces message format as XML or JSON or
but it supports both. But SOAP is XML based message protocol it doesnt support JSON.
Since Google Map APIs support both json and xml , it can be safely said they they are implemented in REST.
Further if you look at the URI of google map api , you will see that they are resources based just like REST URI should be ,for example to get the directions resource you hit this URI
- https://maps.googleapis.com/maps/api/directions/json?origin=Boston,MA&destination=Concord,MA&waypoints=Charlestown,MA|Lexington,MA&key=YOUR_API_KEY
I have searched a lot on web to find a satisfactory answer but I did't get an answer.
Some says RSS is static xml while in web API we make a proper format of request and get a proper format of response
Kindly help me on this
thanks,
The reason RESTful APIs are so inconsistent across different services is because REST is not a standard, it's not a protocol. It's an architectural style. Some things to take into consideration for your API would be; what HTTP verbs to support, what URI structure to follow, how to consistently return error messages, how to handle partial selection, versioning, authentication, pagination, and so on and so forth.. There is no specific right way of doing it (it's debated often), but there are many ways that are not so great!
RSS stands for Really Simple Syndication, which is essentially a format for delivering regularly changing web content. RSS feeds allow a user to subscribe to their favorite news sources, blogs, websites, and other digital properties, and then receive the latest content from all those different areas or sites in one place, without having to repeatedly visit each individual site.
Your question sounds like "What difference is between Ford Focus and a taxi service?" Ford Focus can be one of the cars in a taxi service. But nothing more.
RSS is a standard, which describes specific format of news feed. You can have a standalone locally stored RSS-formatted file, remote stored RSS-file somewhere on a server, or you can have a web-service which constructs RSS-formatted file on the fly. It will be RSS in all three cases because RSS is something that describes internal structure of a file.
Web Service is, basically, an application which runs somewhere on a server, accepts requests, processes it according to the application's internal logic, and then provides answers. Web service can take any kind of requests and provide any kind on responses, including RSS-formatted ones.
Hope that makes things a bit clearer for you.
We will be using RSS as broadcasting channel, who ever wants to know what's happning in my Company can follow my company website's RSS feed.
All the example WCF feed services that I can find are all about generating a feed. What about consuming a feed? Does anyone have any links to examples, or discussions, on a WCF service (.net 4.0 preferably) that can accept an Atom or RSS formatted data feed? I don't need to generate the feed, I need to accept it, validate it, stick the data into a variety of back end systems (DB, Solr, file system). And by accept, I don't mean I go call some service that returns Atom or RSS, I need to let people Post Atom or RSS to me.
I'm currently looking at having a service that accepts a string, then loads that string into some Syndication objects...but that seems clunky. I'm really amazed that there is no one out there needing to do this, which makes me think I'm doing something hinky.
What about a WCF Data Service (RESTful wcf) that only accepts Add, Update, Delete and not Get. I can find no example of that, and it seems like I'd be breaking some major coding standard if I did it.
Any suggestions, links, ideas, alternate designs would be helpful.
Thanks,
Ken
Re: James' request for more info. I am writing a service that will allow multiple, different, data sets to be posted to it. Similar to GoogleBase. There is a loose definition of the data, but a lot of the individual fields are dynamically defined. Other than a standard format (Atom and RSS) and 1 or 2 required fields, the rest is user defined. What I've done so far is have a Service that accepts an XElement argument. I can then determine at runtime if that XElement is RSS, ATOM, or POX, then I process accordingly. I just wasn't sure if XElement is SOAP and REST and CLR friendly all at once. I was also trying to see if there were more standard ways of doing this. If a service that emits data feeds (this is the primary example available) is like a sun, I'm writing the black hole equivalent. It's a data black hole service to help our partners keep us up to date on any changes to their data that we need to be aware of.
Not sure if you are still looking for the answer, i hope not :-)
I was looking for the same thing. Please have a look at the link below. It helped me and it may help someone else also.
http://blog.jschlesinger.net/2009/09/consume-rss-feed-with-wcf-rest-starter.html
Although in the above link the author used program.cs but it is possible to write same code in the WCF service method and expose it.
What things should a developer designing and implementing an API for a community based website know before starting the heavy coding? There are a bunch of APIs out there like Twitter API, Facebook API, Flickr API, etc which are all good examples. But how would you build your own API?
What technologies would you use? I think it's a good idea to use REST-like interface so that the API is accessible from different platforms/clients/browsers/command line tools (like curl). Am I right? I know that all the principles of web development should be met like caching, availability, scalability, security, protection against potential DOS attacks, validation, etc. And when it comes to APIs some of the most important things are backward compatibility and documentation. Am I missing something?
On the other hand, thinking from user's point of view (I mean the developer who is going to use your API), what would you look for in an API? Good documentation? Lots of code samples?
This question was inspired by Joel Coehoorn's question "What should a developer know before building a public web site?".
This question is a community wiki, so I hope you will help me put in one place all the things that should be addressed when building an API for a community based website.
If you really want to define a REST api, then do the following:
forget all technology issues other than HTTP and media types.
Identify the major use cases where a client will interact with the API
Write client code that perform those "use cases" against a hypothetical HTTP server. The only information that client should start with is the response from a GET request to the root API url. The client should identify the media-type of the response from the HTTP content-type header and it should parse the response. That response should contain links to other resources that allow the client to perform all of the APIs required operations.
When creating a REST api it is easier to think of it as a "user interface" for a machine rather than exposing an object model or process model. Imagine the machine navigating the api programmatically by retrieving a response, following a link, processing the response and following the next link. The client should never construct a URL based on its knowledge of how the server organizes resources.
How those links are formatted and identified is critical. The most important decision you will make in defining a REST API is your choice of media types. You either need to find standard ways of representing that link information (think Atom, microformats, atom link-relations, Html5 link relations) or if you have specialized needs and you don't need really wide reach to many clients, then you could create your own media-types.
Document how those media types are structured and what links/link-relations they may contain. Specific information about media types is critical to the client. Having a server return Content-Type:application/xml is useless to a client if it wants to do anything more than parse the response. The client cannot know what is contained in a response of type application/xml. Some people do believe you can use XML schema to define this but there are several disadvantages to this and it violates the REST "self-descriptive message" constraint.
Remember that what the URL looks like has absolutely no bearing on how the client should operate. The only exception to this, is that a media type may specify the use of templated URIs and may define parameters of those templates. The structure of the URL will become significant when it comes to choosing a server side framework. The server controls the URL structure, the client should not care. However, do not let the server side framework dictate how the client interacts with the API and be very cautious about choosing a framework that requires you to change your API. HTTP should be the only constraint regarding the client/server interaction.