What is the main reason that we go for Rest Api in SharePoint 2013. Already we have Client Object Model for implementing application. Anybody can please guide me.
The Client Side Object Model is built upon the REST API so that is one reason for it to exist. For good JavaScript developers they may like the simplicity of the REST API. For people trying to keep their page size to a minimum, they may appreciate forgoing the size of the CSOM and its dependencies. Lastly, in mash up scenarios with other tools, having an easy way to address content via REST urls makes for better interoperability with other tools instead of relying on a product specific API (i.e. the CSOM).
Related
I'm wondering which would be the best approach in 2022 when it comes to working with SharePoint - API wise.
There seem to be a few different possible approaches: CSOM libraries, REST v1, REST v2 (beta?) and MS Graph.
I'm not sure if some of these are the in fact same and thing, just called different things on different sites that I have been reading trying to figure this out.
Can anyone shed some light over this subject - like which are the actual options at the moment, which are the ones to look into and which should be ignored due to depreciation etc?
I think I would prefer REST in some form, but obviously it depends what is offered by the APIs.
ListData.svc
The list data service should be used for SharePoint Classic functionality that isn't supported via SharePoint's Modern API's. I believe behind the scenes JSOM uses the listdata.svc. The listdata.svc is still used behind the scenes by loads of things, but as time progresses it will get phased out.
SharePoint REST v1
This is used by most people as it's mature product etc. I personally use this.
SharePoint REST v2
I haven't really used this, I'm sure I'll have used it at times for specific Modern-only functionality, but tbh, V1 vs V2 doesn't matter yet. V2 might have issues, but you can't escape unexpected issues from cropping up - you still need your solutions to be robust enough to handle unexpected failures.
MS Graph
MS Graph is the future, if you can use it, you should. It is more hassle to use, as you need to set it up etc. It doesn't have all the features either, you will still need to use SharePoint APIs at times but MS Graph is always evolving. If you're making use of other M365 products, then MS Graph is the way to go. That being said, if you're asking these types of questions, you probably don't want to overcomplicate thing and should stick to regular SharePoint REST APIs until you're an expert at SharePoint REST API. The knowledge is transferable to MS Graph.
Personally, I recommend you stick with the SharePoint REST API, and I also recommend you use PNPjs/PNP PowerShell.
I want to understand why client side rendering makes it bad for SEO? Are there any articles about this? Isn't the data rendering already from the server and it's just a matter of making it look like anything we want in JavaScript, how will this affect SEO?
Thank you.
The simple answer is that when you render the site with JavaScript you require JavaScript to see the page, right? Well, Google bots don't run JavaScript so in the best case they'll just see plain text.
Nothing wrong with plain text though. The most important thing is that the same info is on the page even without JavaScript.
Can you be more specific on how you planning to implement client side rendering?
Why would you like to use SEO for a SharePoint site?
SharePoint has already a very good native search engine.
Please take in count that using sharepoint as a public website is no longer recommended, furthermore Microsoft and any SP professional will discourage you from using it in that way. Microsoft has already dropped the public website feature from SharePoint Online (Office 365), and as you may know the current Microsoft strategy is “Cloud first, Mobile first” so you can expect that in the middle term most of the ways and patterns will be equivalent in SP Online and SP on-premise. So I'm not saying that you can't do this with a SharePoint server exposed to internet, however you shouldn't continue doing it, considering that you can use web services to call/get sharepoint content from any other web platform in case you need to publish some sharepoint content in a public website.
http://support.microsoft.com/en-us/kb/3027254/en-us
https://www.linkedin.com/pulse/sharepoint-public-website-platform-any-more-marwan-tarek
Is there any way I can write an Excel VBA program to interface with Quickbooks online? I work for a company that uses quickbooks for accounting, and I'd like to write a simple program that I can run from one of our common excel files to take data from that file and dump into in a Quickbooks bill.
The problem Im running in to is that I dont know where to start. The quickbooks online API online seems suitable for other web apps, and any integration with Excel is online with quickbooks desktop. Are there any good resources? Is this even possible?
You can definitely use the QuickBooks Online API to do what you're looking to do.
The API is usable to both web apps and desktop apps.
If you follow the linked text above there's tons of documentation.
The basic process if you're building a desktop app would be to:
get your OAuth tokens from Intuit's OAuth playground
find an OAuth library for your language of choice
parse the Excel sheet
send OAuth signed REST requests to Intuit's API to send the data to QBO
If you're building a web app instead, you'd be better off implementing the entire OAuth signup process instead of using the playground tool.
You probably don't want to do this from directly within Excel because there's a lot of OAuth signing and other crazy stuff that likely won't be easy/available within Excel directly. But you should be able to use Intuit's .NET DevKit to do what you're trying to do.
I researched this last month. From what I can tell the API is only for creating apps for their app store. The apps have to comply with their standards for navigation, security etc... so the answer to your question from what I can tell is that it's not possible. (I could be wrong but I was asking myself the same question a few weeks ago.)
Probably not the answer you were hoping for but I came to accept it. After talking with my business partner who is a Pro Adviser he said that it was easy enough for him to just upload a csv file if the information was correct and the file was documented.
QuickBooks Online API Diagnostics.php ERROR However, from the looks of this post one might have a reason to believe otherwise.
EDIT The API has been updated. Keith Palmer's answer is correct.
Last week this sample was posted:
OAuthHangoutSamples
I have been using a modified oAuth part of this. I found it was easier to build out the transaction than use the SDK for the API. I have a wrapper class, exposed to com that is working in VBA.
Attending the Intuit's Friday Developer Google Hangout was very helpful in my Intuit Magical Mystery Tour.
A client wants us to develop a Picture Library system for them. The requirements are pretty typical - need to add pictures, tag them with metadata, store different sized versions and so on.
The client is keen on it being developed as a component which plugs into their existing SharePoint system. However, my feeling is that we would be better served building a standalone app - that way we don't have to shoehorn it into a SharePoint page and muck about integrating with SharePoint's APIs.
I am trying to look at this objectively and would welcome any arguments either way that people have.
Using an existing framework like Sharepoint imposes a lot of constraints on the design which makes the software architecture more uniform.
It does require some work on the part of the developer, because the developer does have to understand the API architecture and API's, etc.
However, developing a standalone application is the way that business's software architecture becomes a mix of 200 applications, using 20 different languages/architectures/platforms, half of which were developed by people no longer there - in short, a mess.
Sharepoint is documented, and will be supported probably long after you leave the company. Can you guarantee support for the application that you develop for as long as Microsoft will support Sharepoint?
You should do a cost/benefit analysis of integrating with SharePoint. You have listed some cons for integrating with SharePoint. Here are some pros.
Widely adopted platform.
Existing functionality to store/retreive/update images to data store.
Existing functionality to tag images.
Existing functionality to group several images together and treat as one virtual document (if using SharePoint 2010).
Keep in mind that you can integrate any custom ASP.NET page/application in Sharepoint so you can approach development like a standalone app. Your client wishes might include synchronization with Sharepoint's own picture library functionality and in that case you'll have to work with it's API.
It seems with SharePoint you are already done because it can more or less do what you describe already. What requirements do you have that cannot be met by OOB SharePoint?
I've used picture libraries for something similar before. While they have their quirks you do get a lot 'for free' like a UI, bulk uploading, metadata and 2 alternate sizes rendered.. My biggest gripe is they don't support the datagrid view so I cannot edit list metadata en masse like you can with other list types.
I'm going to need to push and pull files from a SharePoint site that is not hosted by my company (it is external). I'm only going to get a few days (if that) to get this working so I don't have much time to experiment.
To add to my requirements/headaches, I'm going to have to implement this with VBScript. .Net would be preferred for me but for reasons beyond my control I have to use VBScript. I don't have direct access to my VBScript web server, so I won't be able to implement this in .NET and use that object from VBScript.
I'm looking for anything that would help me accomplish this goal quickly and effectively. I found this post and am wondering if the PUT/GET method used here would work for me?
http://weblogs.asp.net/bsimser/archive/2004/06/06/149673.aspx (I got this link from: Sharepoint API - How to Upload files to Sharepoint Doc Library from ASP.NET Web Application)
To top all of this off, I've never done any programming or administration of a SharePoint site. My knowledge of SharePoint is that of a user. I'm aware that there is an API from the few Google searches I did. However, my readings make me believe that my code would need to run on or in proximity to the SharePoint server. I don't believe I have the proximity I need to use the API.
Sincere thank yous!
Regards,
Frank
Progress Update: I'm still researching this. Tom pointed out that the example I had posted is probably from an old SharePoint version. His recommendation to use .Net to develop a prototype on Web Services is good but I'm hoping for more detailed answers.
I'm now wondering if I can accomplish what I need to accomplish using HTTP PUT and GETs. At my company, for a specific project we do use HTTP PUT and GETs to do something like this. We have files that are stored on an HTTP server and this is how we post and retrieve them.
Would this work over SharePoint or would SharePoint require special handling? Basically, do I have to use Web Services?
Progress Update 2: This link is helpful... Upload a file to SharePoint through the built-in web services
But I am still looking for more information on this topic... Thanks all...
You'll need to use the sharepoint lists web service for metadata and get/put for uploads. That link looks to be for SharePoint 2001, so hopefully you can use the newer/simpler version.
I recommend building something in .net first to get the web service calls worked out - some of the parameters can be quite tricky to debug, and I wouldn't want to be doing that on a remote vbscript page.
Assuming there is no metadata required and the SharePoint library is being used like a file server you can do most of what you want with PUT/GET, but you will probably need a call to GetListItems to find the urls to download.
There's an example on my blog of a lower level call to that web service - it's javascript, but probably close enough.
http://tqcblog.com/2007/09/24/sharepoint-blog-content-rating-with-javascript-and-web-services
What setting up the .net version gets you is very quick set up of a connection to the server (just add a web service reference in visual studio) so you can get the query and queryoptions strings working to retrieve the items you want. Once that works you just have to put it all together as a string including the soap stuff for use without all the nice tools.
I'm a little unclear on the context of the implementation and the prerequisite of having to use VBScript. Are the files being moved from one server to another server or from a user's desktop to this SP server? or are they being accessed via software like Excel?
The first thing that sprang to my mind (this may sound crazy) was using the Office application to make the connection. Your script would call up Excel (just as an example) and pass it the vba needed to initiate the Open File, and then provide the full path to the file that needs to be retrieved. Then have it do a Save As to the location that needs the file. Do the same thing but in reverse for putting files on the SharePoint server.
The tricky part, obviously, is getting the script to interface with the Office app. I know this can be done with the Windows version of PHP, but I don't want to get into anything specific without knowing your situation.
I seriously wonder if you are going to be able to use VBScript to call the SharePoint web services. I haven't looked at the SharePoint web services for a while so I don't remember exactly how they are defined. I thought the web services were SOAP calls though which makes it trickier than
I'm not sure I tried to use Excel to call some web services with the MSSOAP.SoapClient and it seemed this component was unable to handle any WSDL types beyond the very simple strings. Anything with nested data would not work. Instead, you would need to create a COM object to process the conversion which is a major hassle. If you are able to use XMLHTTP component then it might be possible with VBScript, but I'm not sure if it will work with SharePoint web services.
I'm not sure what you mean, "I don't have direct access to my VBScript web server." Is your web server in VBScript (ASP)? Or did you mean SharePoint server?
You might consider C# Script (cs-script) as a scripted solution that uses .NET. I have had good success with it, although it does need to be installed on the computer that runs the script.
I'm integrating between two companies. According to this book, we should use AD FS to accomplish what I'm looking for.
I still don't actually have this working though so if someone has more information I will change the answer to this question.
http://books.google.com/books?id=-6Dw74If4N0C&pg=PA27&lpg=PA27&dq=sharing+sharepoint+sites+external+adfs&source=bl&ots=ojOlMP13tE&sig=FjsMmOHymCOMGo7il7vjWF_lagQ&hl=en&ei=ytqfStClO5mMtgejsfH0Dw&sa=X&oi=book_result&ct=result&resnum=5#v=onepage&q=&f=false
I never really received a answer to this that worked out but this is no longer an issue for me.
What we ended up doing is scraping the html. In effect, we put together our own ad-hoc web service processor where instead of SOAP, html is used to communicate. Then we execute GETs, POSTs, and etc to work with the web service.
We had done something similar in VBScript in for WebDAV -- we had a class and created a new one to work with SharePoint.