The documentation here and here seems to be saying that I can only filter strings with exact matches "Supported Operators for Strings :EQUALS:"
I'm using the IPP .NET Devkit so my search looks like this:
CustomerQuery qboCustomerQuery = new CustomerQuery();
qboCustomerQuery.Name = "Southwest";
List<Customer> customers = qboCustomerQuery.ExecuteQuery<Customer>(context).ToList<Customer>();
However I need to find a customer name that contains "Southwest" in it. Is my only choice really to cache the customer names locally and search my own db? This seems asinine. Please tell me I'm being an idiot and that this system isn't really this obviously broken.
Unfortunately, the Intuit Anywhere APIs really are this crappy at the moment. :-(
Here is the list of filter operations that are supported for strings:
https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0400_QuickBooks_Online/0100_Calling_Data_Services/0030_Retrieving_Objects#Supported_Filter_Operators
Note that the only one supported is:
:EQUALS:
Ick!
Fortunately, Intuit is hard at work on the v3 APIs. It was rumored that v3 will support better filtering.
Unfortunately, Intuit is doing their usual thing and not involving developers in the v3 dev process anymore, so we really won't know whether or not v3 is going to suck until it's actually released. sigh You'll notice the last update about v3 data services was in October by Wei... unfortunately Wei isn't even on that team at Intuit anymore, so who knows what the status is, or even if there's anyone at all working on v3 anymore at Intuit.
I had to do something similar. Sadly, as Keith pointed out, it is not yet supported. What I ended up doing with this was fall back on LINQ.
I read in all of the customers, and then filtered using LINQ. This prevented me from having to write and read from a db and speed things up by keeping the data in memory.
So, for now, try LINQ. Hopefully we will get a better solution when v3 comes out.
Related
My question is related to the recommended way (going forward) to talk to on-premises Exchange mail box and perform operations on it from an external application programmatically?
EWS APIs and the corresponding SDKs look promising based on a few articles such as this :
https://blogs.msdn.microsoft.com/webdav_101/2018/06/19/about-using-ews-and-powershell/
but there is bit of confusion on whether it will continue to be supported in the future based on this:
https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/
Although the above talks of just o365, the fact that EWS will no longer be invested in, raises the question if new applications for on-premises exchange should continue to use it.
PowerShell, remote PowerShell etc. also might work but it seems less suited for use/integration within an external application and more so for automating operations.
Could someone please throw some light on what is recommended way going forward to work with on-prem Exchange?
Try the Microsoft GraphAPI. Details https://developer.microsoft.com/en-us/graph/graph-explorer here. Sign in. Try the https://graph.microsoft.com/v1.0/me/messages sample. See more examples by clicking "Show More samples" on the left column after you login.
Is it The Way (tm)? I don't know but is very cool. I have some sample code I'm working with, nothing in a format to share, but look like the API covers a lot of territory. Some client-only rules look like they need some work to expose, maybe they'll get beefed up in later releases.
Depends on the type of Application you are trying to write, EWS is going to be around in Exchange 2019 so it will work just fine talking to say 2013, 16 and 19 OnPrem. There are advantages and disadvantages to using EWS vs. the new REST API's but it is application specific and changing fast. But again it depends entirely on the type of Application you are trying to write and what version of Exchange you need to support. And typically newer features that will appear in new OnPrem versions aren't back-ported into older versions. So a great new feature that will work in Office365 and Exchange 2019 may not work in 2016 and you may need to use some of the older legacy API's to achieve the same thing. Bottom line as of today if you are an ISV and need broad coverage support for versions of OnPrem Exchange expect to need to use both EWS and REST. If you are just creating apps for one organization that's going to be migrating to 2019 in the future you'll probably get away with just REST.
I need to develop REST server strictly accrding to jsonapi.org specification and I'm not sure if there is some complex solution or even if it's easy to develop such thing.
I've found sails-hook-jsonapi, but it looks unmaintained for some time.
I'm new to Sails and not aware of all it's features and would appreciate any help, I may missed something obvious.
I have needed this too. There is not anything that works yet with Sails. sails-hook-jsonapi does not work correctly. I Forked that code and am maintaining my own version of it but there are still significant attribute serialization issues with multiple records. However, it does work at a basic level. I am also working on a new project sails-generate-jsonapi-blueprints but it is not nearly ready yet.
Sails is great but can ba a royal PIA. The guys maintaining Sails have had many requests for jsoanapi.org support but I do not believe that will happen anytime in the near future. If you REALLY must have JSONapi.org format I would suggest Loopback or some other API that already has support for it out of the box.
Actually, I take part of that back. sails-hook-jsonapi is working. I made a little change in the fork I maintain. https://github.com/NikkiDreams/sails-hook-jsonapi. Ian is maintaining the original project fork too I believe. https://github.com/IanVS/sails-hook-jsonapi
So the catch about the hook is that it hijacks every single request sent to responses/ok.js If you need something like an Authorizer that does not need jsonapi create a variant of ok.js that simply does a res.json(data) without the jsonapi-serializer being called when serializing the response.
sails-hook-jsonapi will serialize most of your data to your needs. But it still has a few limitations. Depending on the complexity of your queries these may not be an issue.
TODOs: Included request parameter handling (400 response if present)
Links
Top-level "self" links
Top-level "related" links
Resource-level "self" links
Related resource relationship links
Metadata links
Pagination
Formatting
Non-dasherized attributes
Sparse fieldsets
Long story short - there is no way to do it out of the box with little time investment. At least for now.
But sails-hook-jsonapi looks like good starting point, repository seems to be active now.
I've done project prototype on loopback.io framework, because I was in hurry and loopback had better jsonapi support.
How does one block/ban one user from a SoundCloud group via REST API?
Logic:
Though not in the docs (but then again, lots of other wrong info is there), one would expect that this should work:
DEL api.soundecloud.com/groups/{id}/members/{member_id}
Note:
Taught by my previous experience, I did not venture into testing any of my ideas since there is probably no way to guess how developers got it implemented, if implemented at all.
I played with the Intuit AnyWhere API about a year ago and at that time, there were some reporting entities such as the balance sheet and income statement. I notice now in V2 and V3, all that has disappeared. Does anyone know if there are any plans to add it back in? Seems like a fairly large omission given the functionality of the QB SDK.
In v2, the reports are definitely still supported for QuickBooks Desktop. Docs are here:
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/v2/0500_quickbooks_windows/064_reports
QuickBooks Online has never supported any form of reporting.
As far as v3 goes, it's still in private beta, so everything is pretty much still up in the air on that still.
I am about to start a new project in the Google Analytics API & PHP.
I read that Google Analytics will be deprecating XML v2.3 and v2.4 and in 6 months time, so aparently you will only be able to use v3 and retrieve information in JSON format.
http://analytics.blogspot.com/2011/12/introducing-google-analytics-core.html
My question is the following: Does this means that GAPI class won't work any longer? Anyone who has used this class before can help me answering this question ??
http://code.google.com/p/google-api-php-client/
In that case, any alternative suggestions of PHP classes that do the same thing.
Thanks so much
I've been using GAPI for a while now. And I can say with some confidence that yes it will break, if not due to XML it will be due to some other change google makes.
Having said that GAPI is the best solution I have found out there for php. It does break every 6 months to a year, usually needs one or two lines changing to fix. But GAPI is pretty popular so at least you know when your clients are calling saying analytics is throwing errors at them, you wont be the only dev tearing your hair out.
9 times out of 10, by the time I've got a problem someone else has found the fix - which is nice.
There are a few other php options out there but GAPI seems to be the most popular (usually the best way to go imho)
My approach is to build an analytics summary in the dashboard and provide a link to google analytics underneath so clients can see the full data or go there when GAPI breaks. I have been putting all my sites on the same modular system for a while now. I keep GAPI as a library in my admin layout module, this means I can make the fix once and roll it out to all my sites without too much drama.
In summary, use it but expect it to break - that way you wont be disappointed when it does.