I am very confused. I have a xsd file, no wsdl and apparently i send this data through SOAP. Now looking at all i went back and notice this
(using ssl) The regular session begins
with a HTTP POST request sent by the
client. The body of the request
contains XML document compliant with
SOME_API Request schema
So... i am not using SOAP at all? Am i suppose to do something with the schema file they provide me? No one here (at work) seems to know.
You should start by reading Http made really easy. Soap uses http to send its messages from client to server, and when the document you are talking about is asking you to send a message to the soap server using the HTTP protocol. A bit of googling should find you some nice soap getting started guides.
The message you send is an XML document that uses this schema. The schema defines the types of XML that are valid. Get a good XML editor such as oxygen and tell it you are making a new xml document using a schema (point to your xsd file) and see what you are allowed to type.
My search turned up these two:
Tutorial point SOAP Tutorial
W3Cschools
Just send an HTTP POST with XML that complies to the schema. You can either read the schema manually (which can be hard), or use an XML editor like Tom is suggesting, but there's another possibility: Many platforms offer tools that automatically generate classes from XSD schema, which you can later automatically serialize to get the correct XML.
For example, if you use .NET: Use the xsd.exe tool to generate classes from schema, then just fill these with information as regular classes, then use the XmlSerializer to convert the root class to XML.
Based on your description, it seems that it's not really a SOAP API at all, but rather something like XML-RPC.
Just send an HTTP POST with XML that complies to the schema. You can either read the schema manually (which can be hard), or use an XML editor like Tom is suggesting, but there's another possibility: Many platforms offer tools that automatically generate classes from XSD schema, which you can later automatically serialize to get the correct XML.
For example, if you use .NET: Use the xsd.exe tool to generate classes from schema, then just fill these with information as regular classes, then use the XmlSerializer to convert the root class to XML.
You are learning why standards should be followed.
If this is really a SOAP-based web service, then there must be a WSDL. There is no exception to that. The WSDL is meant to describe everything you need to know about the web service. I strongly suggest you ask the developers of the web service whether it is a SOAP web service, and ask them to supply a WSDL or to explain why they think they should not do that.
Related
I'm designing a REST API (implemented with ASP.NET Web API, not ASP.NET core, because we can't upgrade it right now).
I'm looking for the best solution to partially update an entity.
For example, the "Person" entity has 100 properties, and a third party system only has to update the "PersonValidityDate".
What is the best and simplest solution to do it ?
I read some article about the PATCH verb, with JSON patch or JSON merge patch, but it seems a bit complicated and not supported by everyone... Is it ?
I'm looking for a very simple solution to do it, that any integrator can understand and use...
What do you suggest ? Is PATCH often used?
If I use POST/PUT and only give the properties to update and ignore the other properties, when the body is deserialized, nullable properties will be null. How can I distinguish the properties set to NULL explicitely and not provided properties ?
According to RFC 5789
Several applications extending the Hypertext
Transfer Protocol (HTTP) require a feature to do partial resource
modification. The existing HTTP PUT method only allows a complete
replacement of a document. This proposal adds a new HTTP method,
PATCH, to modify an existing HTTP resource.
So you should use a PATCH request for partial update of the object and PUT for complete object replacement.
And you should not use the complete model in patch request with empty/null fields instead use the new model for PATCH request.
You can check more example here
I am already using the standard WebAPI and returning JSON objects to my client. Now I saw an application that returned OData.
Can someone explain if there is any reason for me to use OData if I do not want to query my data from anything other than my own client running in the browser. Are there advantages that I could get through using OData ?
If you are only using your data in your own browser application, there is only few advantages to use OData in your situation:
OData is able to provide metadata about your service interface that can be used to generate client code to access the service. So if you have lots of client classes that you need to create, this could speed up your process. On the other hand, if you can share your classes between the server and an ASP.NET based client or if you only have a few classes, this might not be relevant in your situation.
Another - bigger - advantage in your situation is the support for generic queries against the service data. OData supports IQueryable so that you can decide on the client side on how to filter the data that the service provides. So you do not have to implement various actions or use query parameters to provide filtered data. This also means that if you need a new filter for your client, it is very likely that you do not have to change the server and can just put up the query on the client side. Possible filters include $filter expressions to filter the data, but also operations like $skip and $top that are useful when paging data. For details on OData and queries, see this link.
For a complete overview about OData and Web API see this link.
Here are few advantages of OData.
OData is a open protocol started by Microsoft is based on Rest Services so we can get data base on URL.
It suppport various protocol like http,atom,pub and also support JSON format.
No need to create proxy classes which we used to do it in web service.
You will able to write your own custom methods.
It is very light weight so the interaction between client and server will be fast compared to web service and other technologies.
Very simple to use.
Here are few reference links.
http://sandippatilprogrammer.wordpress.com/2013/12/03/what-is-odata-advantages-and-disadvantages/
http://geekswithblogs.net/venknar/archive/2010/07/08/introduction-odata.aspx
http://www.zdnet.com/blog/microsoft/why-microsofts-open-data-protocol-matters/12700
I agree with the answers already posted, but as an additional insight...
You mentioned that:
... if I do not want to query my data from anything other than my own
client running in the browser...
You may not wish to run it normally through anything but your own cilent, but using oData you could use other querying tools for debugging. For example LinqPad allows you to use oData endpoints (such as that provided by stackoverflow).
It's probably not a good enough reason to implement oData if you don't have another reason to do so, but it's an added bonus.
Could someone please be kind enough to show me the best way to determine if a webservice (ASP.NET) exists at a given URL?
I assume an approach will be something along the lines of issuing a request using System.Net.Webclient but how could I determine if it is a valid webservice and what sort of request should I issue?
EDIT: To add a bit more context I am determining if a webservice exists because I am attempting to build a generic tool that uses arbitrary webservices.
The only way IMHO to be sure the service is up is to be able to call an innocuous method on the service and verify the response. Retrieving the WSDL is not sufficient.
There is a similar SO question on this here:-
How do I test connectivity to an unknown web service in C#?
I would ask for WSDL document. If you get it back it means that the service exists and you can check to WSDL for implemented methods.
Consider reading about WS-Discovery
http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.html
I would like to pass an arrayList of objects to a servlet from a java program.
Can some one please tell me, how this can be done.
Look at this link they describe the process ind detail
http://www2.sys-con.com/ITSG/virtualcd/java/archives/0309/darby/index.html
Please note that if you are going to serialize objects back and forth that the compiled version must be in sync on both the client and the server or you will get errors. I would recommend converting your objects to either XML or JSON and then reading them from that on the server side. That way if you client and server code get out of sync it will still work.
For the client I would recommend Apache's HttpClient (or whatever they have renamed it to)
Have you considered using a web service framework for this instead of coding a naked servlet? The whole business might be about 10 lines of code using, for example, an Apache CXF JAX-RS service and client. If the objects are complex, you might want to use a full SOAP service.
I am aware of Web Services and WCF but I have generic question with services.
I have a ASP.NET MVC Application which does some basic functionality. I just have a controller in which I am passing it the records and serializing the information to XML using XML Serializer. Then I return this information to the browser and it displays me the XML i got from the Controller Action. So I get the XML representation of my Class(Database Object) in XML and I am to give the URL of this application to the client and access and pull the information.
Is this a Service then?
I mean in the end all the Clients need is the Xml representation through services also right? I am not that experienced and probably being very silly but please help me out...if I provide xml this way to the client is that a Service? Or is there something I need to understand here?
Don't let all the buzz about "web services" fool you; the basic idea behind a web service is very, very simple. It is simply a matter of providing data in response to a request over standard web transport protocols (i.e., HTTP/HTTPS). Everything else (XML, SOAP, WSDL, etc.) is just layered technology to augment the basic functionality of a service. REST-based services are very basically the simplest services that you can build--they are built on the core HTTP/S transport protocol and not much else.
The main differentiator between a service and traditional web site is that a service is data-focussed rather than presentation-focussed; that is, services typically are not concerned with how data is formatted and displayed (that is up to the client), but rather what data is returned. So...you are delivering XML data over HTTP? Check. You have a service. Congratulations!
Yes, it is a service, returning an XML resource. Also it seems that it is accessible throught standard HTTP verbs such as GET, so one might assume it is RESTful. The difference with a standard SOAP XML service is that you don't have a WSDL that describes it, so you might need to provide a good documentation to clients wishing to consume your service.