We have some XML restful services implemented in MVC (C#). Their overall look and feel is very similar to http://www.zendesk.com/api.
Now we need to accept some files uploaded.
The services are intended for consumption from PHP / Python / ruby and other popular web development languages.
How should we do it right? multipart/form-data? or just read post body?
I'm concerned about the ease of use from mentioned languages and popular web development frameworks. Unfortunately, i don't have anyone to ask on consumer side.
I'm also concerned about memory consumption. As i understand, multipart/form-data will be converted by MVC / ASP.NET to HttpPostedFileClass which caches itself on the web server disk. But plain POST won't, so it will consume IIS memory?
Maybe there are other notable options to consider? What do you think?
This sounds like a very standard content management application, which REST excels at.
The most straightforward way would be to PUT to a resource whose name is a single file, say http://www.example.com/myfileserver/folder1/folder2/myfile Then you GET the same resource to download the file, PUT to update the file, and DELETE to get rid of it.
In REST, the HTTP operation verb is crucial: POST is designed to add a new resource to the server when you don't know the resource name and the server assigns it. In your case you use PUT, which creates or updates a resource for which the name is known beforehand.
Related
I am going to deploy a SOAP web service on a WebLogic server.
The endpoint of the service is something like:
http://myserver.mycompany.com:1234/MyService-0.0.1-SNAPSHOT/MyServiceService
However, if (using a browser), I navigate to either
http://myserver.mycompany.com:1234/MyService-0.0.1-SNAPSHOT/MyServiceService?WSDL
-- or --
http://myserver.mycompany.com:1234/MyService-0.0.1-SNAPSHOT/MyServiceService?xsd=1
I can see the WSDL or schema file, respectively, for the service.
My group does not deploy a lot of web services (we're a back-office group and use Oracle Middleware to automate what little services we do provide), so a question has come up regarding whether exposing the WSDL file and schema file is "best practice".
Is it OK for these files to be visible, or should access to them be shutdown somehow? Conversely, is it even possible to restrict access to them, or would that interfere with clients trying to access the service?
This is an old question, but anyway.
It depends, but in my projects it was considered a bad practice to do so. You should always do Contract first, don't base your WSDL on your code or most likely you will end up with a WSDL that is somehow dependent on the programming language used for the implementation.
I don't know how Weblogic behaves but I remember that Jboss (5) used to generate the WSDL from the code any way and serve that. Even when we did Contract (WSDL) first development. So you would end up with little differences in these WSDLs which may cause problems. Exchange of the WSDL and the XML Schema files should be done by other means. It is possible to restrict access to any URI on Weblogic.
Another aspect is, that if you don't remove these, we found the developers on the clientside will start pointing their development-tools and implementation to these endpoints to get the WSDLs. This will most likely also cause problems and at least (a lot) unnecessary downloads of these files. As most frameworks will (need to) read the WSDL every time they instantiate the client-code. By not providing these endpoints, you keep the clients from these bad practices.
When I'm tasked with dealing with connecting to web services, I've always found the appropriate .wsdl file, ran WSDL2Java.bat, and incorporated those Java files into my Java project. Then I've successfully completed my project that needs to access data via web services.
My question is, are there other ways to use the .wsdl file to access web services? ( I'm not talking about creating classes for different languages ). For example, I have documentation describing one company's web services. The examples it shows in it's documentation are essentially dumps of HTTP Post requests. Is this "web services"? It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right? I really feel like I'm missing something here.
Am I a web-services illiterati?
To call a SOAP web service over HTTP you just need to send it a properly formatted XML with a POST request. That's it! How you build the request is irrelevant as long as it conforms to the SOAP protocol and the payload corresponds to a proper web service operation that exists on the particular web service you are calling.
But how do you know how to build the proper payload?
The web service needs to have some sort of documentation otherwise you don't know what to put inside the XML. The documentation can be whatever you like as long as people can use it to build valid requests. WSDL fits this criteria but has an extra advantage: you can feed it to a tool that generates code. That code knows how to handle all the SOAP details and exposes objects and methods to your application.
What would you prefer? Generating code from the WSDL in a few minutes and be able to call whatever operation on the web service or, build the requests and parse the responses by hand and spend hours or days doing so. What would your boss or company prefer? :)
It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right?
Right! But you also have to consider your productivity as an employee in one case as opposed to the other.
I have a situation where two components are being designed that have some similar presentation requirements, but have been built using different technology stacks (one is java and the other is .net). For one feature, the developers are propsing using a web service that returns HTML so that both components can re-use the same display logic. I have been told that it is a bad practice to use a web service in this fashion, and that a web service should focus only on data.
In terms of web-service or SOA best practrices, should you return HTML from a web service?
If it's actually a web service (i.e. meant to be called by scripts), HTML is a bad idea, as you'll have a difficult time handling error situations.
A well-designed XML or JSON answer is probably the way to go these days.
Can some people offer some light on the following questions? I believe that the following questions are very much debatable, but I just want to know the mere facts which will enlighten me & of course many others viewing this general question post.
Why does Magento API produces Web Service Responses in XML format & not in JSON format? There should be some advantages in producing the responses in XML format. I want to know those advantages mainly.
In Magento terminology, there are two API versions mentioned - "Normal API" (api/soap) & "API v2 (api/v2_soap)". What's the difference (mainly the advantages) between these two versions, & where does WSDL fit in?
If I'm to create a new Web Service, should I be targeting SOAP v1 format, or the SOAP v2 format, or both of these formats?
Can the Web Service create a general definition of WSDL, based on my requirements, in Magento? What I want is that I want to know whether the "wsdl.xml" file (residing in the "etc" folder of the Magento module) for any particular Magento API module can be generated dynamically? If I provide my required API method name, along with all the property names, types, and also the Response data types, then will I get the "wsdl.xml file dynamically generated with all the Complex Types & Methods & Messages properly mentioned?"
If possible, please provide some good links, from where this spider-webs of Magento Web Services can be thoroughly cleared.
Also, please consider my expertise in this field of Web Service as a novice one, so that based on any valuable input, I can re-frame the question.
Help appreciated & thanks a lot to everybody.
My Main point of asking this question is that I want to make new custom APIs which can be used by any systems, whether it be ERP / CRM / SAP / Cloud / anything in general.
P.S.
I tried posting this question in the Programmers Stack Exchange area, but due to the lack of available required tags (like magento, wsdl & soap), I had to post it here. If possible & required, please transfer this question to proper stack exchange area.
API is not for ajax(frontend), but to integrate Magento (frontend shop) with different ERP, CRM, SAP (backend tools) systems - to import data and get reports. That's why it's using XML.
This is not magento's terminology. This is done mainly for legacy support. So you have to use lates one - v2.
What means general definition of WSDL? WSDL describes published functionality - available calls/resources. If you don't need it you need to overwrite configuration files to not publish everything but only necessary ones or do this form admin area.
Could you tell more clear and more technically what do you need to do with API?
The API works great for normal PHP programming where you want to get something out of Magento. 'Normal' API works fine with PHP, furthermore, the resultant XML is very easy to work with in comparison to the XML that gets churned out by other APIs.
Some people have said that the Magento API is slow, which it is. However, if you move the same code into a Magento program then it still takes forever, the API code isn't much of a burden.
I used WCF to create a restful web service in .NET, by means of a .svc file. The web application automatically produces a WSDL file. AFAIK, the WADL is more natural for a restful web service.
How could I create a restful service in .NET (preferably with wcf) that produces a WADL description?
Note An answer like "RTFM" is accepted, as long as you indicate a suitable manual/tutorial.
This is an old question but having consumed restful services with WADLs they do offer some value. You can import them straight into SOAPUI and it will build a test suite for you automatically. Secondly they tend to contains all the required XSDs for XML based services and are useful for automatically building serialisable classes that your endpoints accept and receive.
Looks like REST Describe & Compile should do the trick.
On the WADL developer site Marc Hadley
maintains a command line tool named
WADL2Java. The ambitious goal of REST
Describe & Compile is to provide sort
of WADL2Anything. So what REST
Describe & Compile does is that it:
Generates new WADL files in a completely interactive way.
Lets you upload and edit existing WADL files.
Allows you to compile WADL files to source code in various programming
languages.
Forgive me for answering a question with a question, but do you really want to do REST? REST really has no need for things like WADL.
Update:
The "hypermedia constraint" (aka HATEOAS) dictates that the user agent discovers content based on links embedded in previously retrieved content. It really is unnecessary to have a separate document that describes all the available content.
Imagine using a web browser to go to a site and instead of going to the home page and navigating from there, you are presented with a page which is a list of all the URLs on the site. You must then looks through the list of available urls, choose the one you are interested in and copy it into the address bar.
WADL is effectively you list of site urls. You just don't need it if your main content is linked together.
Linking content instead of using a WADL "site map" has other advantages. The available links can be dynamic based on particular data values in the content. This capability can vastly reduce the complexity of clients, because the client no longer needs to host the logic to decide when it is allowed to follow a link.