In one of my project I am trying to retrieve some content from Sitecore (multilingual). Can anyone here point me to the right direction/ best way of doing it? I have seen in some of the posts it’s mentioned about the web service or REST API. Can anyone point to a documentation or code snippet on how to do it?
This is quite a vast topic, but Sitecore doesn't limit you here. The general note about it is mentioned in paragraph 1.2.7 "Web Services, AJAX, and other Internet Interfaces" of this article.
I would recommend you to explore the standard Sitecore web service (it is present in any Sitecore release). Type http://yourhost/sitecore/shell/webservice/service.asmx to get an idea of what it can offer. It consists of just basic operations, but those are enough for the most of cases.
Related
I'm sure I sound like a total noob with this question, and I've looked at a couple posts that are basically asking the same question in the title, but the body didn't give anything helpful to my skill or knowledge level.
In this post the OP mentioned that they did some "digging and drilling" to find out that there was a web service in REST format. In another post I found that the OP was using "web console" to look at the activity of a website they were visiting.
I would really like to have more knowledge and methods for finding web services that I can reference and use is some of my new or updated applications, whether RESTful or not. In summary, how do I "dig and drill" to find that a site has a web service I can use programmatically?
The only sensible way to find web services that you can use is to ask.
If the service is intended for your use, then you will be told that.
If the service is not intended for your use, then you will be told that.
If you use a service that is not intended for your use, then that will generally be a bad thing.
I want to write a .NET application that will interface in realtime with Dynamics NAV 2009 and 2013. The application will have to read and update entities such as customers and stock items.
Using the provided webservices seem to be the best candidate as a point for integration, and I've tried some basic tests reading, updating and creating items using webservices based on Pages and a .net client.
Unfortunately, I am very new to Dynamics, and I have some questions that probably reflect that lack of experience.
First - webservices can expose either Page or Codeunits. Is Page the correct option to use for interfacing to say - create a customer?
Secondly - My understanding is that Dynamics NAV is rarely deployed without customisation. Would a typical customisation in NAV e.g an addition of a field involve changing a standard Page, and will this change then be reflected in the webservice definition?
You are right - given your requirements, webservices are probably the best option for interfacing with NAV.
Regarding your first question: page web services know how to handle concurrency, and, thanks to the way Visual Studio encapsulates them, expose rich types that you can interact with from your .NET code. All the basic CRUD operations can be carried out using the exposed methods. For a more detailed comparison between codeunit web services and page web services, please refer to http://msdn.microsoft.com/en-us/library/dd355398.aspx.
I think most developers choose not to publish the normal pages (the ones aimed at the NAV Windows Client; previously known as the Role Tailored Client), but instead, create separate, tweaked pages for publishing as a web service. But, if you prefer, I guess you could add your custom field to the standard page and publish that as a web service.
Hope this helps! Good luck! :)
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'm trying to upload documents to SharePoint using web services attaching custom metadata to the files. I've searched but have not found a good tutorial covering all these topics. Can anybody point me in the right direction?
Here's why I think I need to use web services:
I'm developing on XP and the Sharepoint object model is not remotable. This means any code which has "using Microsoft.Sharepoint" is out :-(
I'm looked into the CopyIntoItems web service but am having trouble implementing it myself. I was hoping for a clear tutorial. I've tried using the sample code from http://msdn.microsoft.com/en-us/library/copy.copy.copyintoitems.aspx , but I'm not sure what my sourceURL should be. Also, since I can't use "Microsoft.Sharepoint" references, I'm wondering what my Fields will look like? (Is this my metadata?) Also, I'm curious as to why only Website projects allow me to add a web service.
Once the file is "in" Sharepoint using that web service, I'll have to use another one to update custom columns, or metadata. Some of these are freeform text, but other must match entries in lists or lookups. I haven't found any information on this yet.
Thank you for your help!
Here is some code http://geek.hubkey.com/2007/10/upload-file-to-sharepoint-document.html
As for why it is that is the way because Microsoft wrote it that way :). Some people have written custom web services that combine them, http://www.sharepointblogs.com/ssa/archive/2006/11/30/wsuploadservice-web-service-for-uploading-documents-into-sharepoint.aspx
Using the built in web services you have to upload the file and upload CAML which contains the columns. Another option if you are using a MS-Office document is to make sure the author fills in the properties in the document then you can have those fields displayed in sharepoint.
Here is some stuff on the Sharepoint Designer - http://office.microsoft.com/en-us/sharepointdesigner/FX100487631033.aspx
Hope that helps a little.
You can link to the Sharepoint 2007 training from here: http://office.microsoft.com/en-us/training/HA102358581033.aspx
The designer I believe has a WS example in it.
Does anybody know a wiki engine that can be built on top of a RESTful application?
I have a restful application, that exposes a document resource,
I want the wiki engine to use the REST API to persist the documents, instead of saving them to a DB.
I am also open for suggestions of an open-source wiki engines that can be easily modified to support such functionality.
As Wikis were originally designed to work in a standard browser, and most browsers did not support anything except GET and POST, REST is not a concept used a lot on the wiki world. However, nowadays, some wikis (foswiki - the community fork of TWiki for instance) provide you a REST API to it http://foswiki.org/System/CommandAndCGIScripts#rest ).
But you need the opposite: a wiki with a customizable backend (storage) that could be plugged on top of a REST storage service. As wikis with a pluggable backend, I know only of pmwiki http://www.pmwiki.org/wiki/PmWiki/PmWiki and foswiki (the open fork of TWiki) http://foswiki.org.
Okay, this is a puzzler. Wikis in general are more or less the canonical example of a RESTful approach. The page name names a resource. What do you want that isn't in, eg, Twiki?
While you could try to find a wiki that can use a REST backend, it may be better to write a small wiki yourself. Because even though a your backend has REST interface, that doesn't mean you can put some other application in front of it.
dokuwiki does not use a database. It is a filesystem based wiki. I don't know its internal code structure but you might be able to use it as your base.