Paging in rest API is not working
/maxrest/rest/mbo/ticket?_maxitems=20&_rsstart=31
Modifying value of rsstart is giving same result
Not sure if you're still having this issue but I'll post an answer anyway for people looking in the future.
The naming of the parameters is "supposed to be" case sensitive. That being said I've run into Maximo instances where it seems to not matter, and other instances where it will only work with proper syntax.
I presume that you are building your own paging logic since I don't believe it is not natively supported by the REST API.
The url you should be using is:
/maxrest/rest/mbo/ticket?_maxItems=20&_rsStart=31
Related
I need to use the table in from this wiki page https://en.wikipedia.org/wiki/List_of_most_visited_museums to make a database in python (though the latter part is irrelevant atm). I have to use the API (can't scrape) to access it. Right now I'm trying the API's documentation https://www.mediawiki.org/wiki/API:Parsing_wikitext#Example_1:_Parse_content_of_a_page Example #2 from this page is exactly what I want to do, but it's returning an error, and even running the original code in my notebook it also returns an error. Can anyone tell me how to either alter that code so it runs, or direct me to another way to do the same thing? Thanks.
This fetches the content you're after: https://en.wikipedia.org/w/api.php?action=parse&page=List%20of%20most%20visited%20museums&prop=wikitext§ion=2&format=json
If the example isn't working in your notebook, the problem probably lies with the rest of your code and not with the API call.
By going through this API documentation page, is it possible to tell which database is being used in the backend?
Zomato API
MySQL would require a php file on the server to handle the requests, make queries, pack data in JSON format then send it back to the device. But in this case parameters are passed to .json files. Please advice
There is no way to "see through" to what the backend service actually used to provide you with the information you may query for. Are you sure you want to continue using this product? The site notes that Zomato will no longer be available to individuals, and that your API key will be disabled if you don't use it monthly.
I haven't read the specs for that particular API. But in general, is it possible to tell what database is being used on the back end by studying an API? No. That's the whole point of an API: It's supposed to shield the API-user from implementation details.
It's probably true that in many cases you could make reasonable guesses about what tools are being used on the back end. Like if you see that the API gives you a syntax for doing comparisons that looks exactly like the proprietary compare function used in Foobar SQL and not found in any other database product, that would be a strong clue. But even something like that wouldn't be proof. Maybe originally they were using Foobar SQL, then they switched to another database, but to maintain compatibility they wrote code to translate the Foobar SQL compare to standard SQL syntax.
I just noticed that my application can not remove a like on a media object. My code for liking / unliking is identical except I add the parameter _method=DELETE to the unlike case (both use POST). The documentation states that this is supported, and it's pretty common for RESTful API given the lack of support in most browsers for DELETE. I've tried in from the Apigee console too, and the same problem seems to exist, however DELETE does seen to work. I'd attach screenshot from the Apigee console, but apparently I need more points or something.
Yes, this is really supported, but it has been broken since February 3rd. It has now been fixed!
What is the best way to avoid SOQL Injection when querying salesforce through the APIs?
The two main APIs I am interested in are the SOAP and REST APIs.
My current methods are to never use any input from the user (which is impractical if they are searching for a Company Name) or encoding certain characters within the string.
However I saw that there was parameterisation within the APEX, so i was wondering if there was a similar way of doing it through the APIs.
I think all you really need to do is to make sure that the input, in this case the company name, is escaped properly. I am not aware of a parameterized way of building a query object for either of the API's.
However, if you needed to you could expose a custom web service method from within Salesforce so that you can pass the value in. Then from within the Salesforce Apex Code language you can parameterize the value using a syntax similar to below:
public Account[] queryCompany(string companyName) {
return [SELECT Id FROM Account WHERE Name = :companyName];
}
Philosophical rant
What are you after really :)
If your application should work same way accessed from different sources (Salesforce UI, PHP connector, some mobile applications) then it probably makes most sense to think about Apex like some stored procedures that will be reused. This means you'd be passing safe parameters to them.
If you plan to hand-craft queries & not rely on Apex too hard - maybe what you need is something like database.com or other cloud-based DB solutions?
Actual answer
I'm not aware of an out of the box way to pass separately the query command and separately the params to it (like bind variables/prepared statements) through APIs. Both REST and SOAP API give you what's essentially Database.query() within Apex. Sure, there are some differences like retrieve() command or queryMore() but that's the baseline.
What you could do is to either expose some commonly used searches with methods similar to what John proposed (bonus points for extra performance - they're precompiled) or build something generic?
List<sObject> runQuery(String query, List<List<String>> params){...}
If the runQuery will contain bind variables like params[0] it should work. Looks crazy and I didn't test it though ;) I'd say that bind variables are the best method. Alternative would be to escape user's input but SQL and XSS injections can become amazingly creative. Check Examples of XSS that I can use to test my page input? for a start (yes, I'm aware you asked about SOQL only).
As for actual SOQL injection: http://wiki.developerforce.com/page/Secure_Coding_SQL_Injection. Since "worst that can happen" is that users will search for more than they were supposed to (no way to convert SELECT into INSERT) escaping should be safe-ish...
I'm writing a webapp that uses the YouTube Code API to do specific types of searches. In this case, I'm trying to search for all videos that match a query, and which were uploaded between two dates. This document says I can use published-min and published-max parameters, while this one says I can use updated-min and updated-max.
Both of these parameter sets cause YouTube to return an error:
published-min returns "This service does not support the 'published-min parameter"
updated-min returns "This service does not support the 'updated-max' parameter"
With neither returns a correct result set.
How can I limit my result set to hits within a specified date range?
The Reference Guide for YouTube's Data API doesn't list anything that would suggest the possibility to filter on time interval in general.
The published-min argument is only advertised in the "User activity feeds" section which is something different and probably not the thing you wanted. Or is it?
The updated-min argument in your link is referenced in a generic gdata context. It looks like they intended to describe all the things common to all the specialized APIs, but somehow updated-min isn't available everywhere.
When it comes to your very problem. I would suggest sorting on time (orderby=published) and do the filtering on the client side. I know this is not the optimal way, but the only one I can see with what Google gives us.
youtube api v3 supports publishedAfter and publishedBefore parameters with search results. For example:
https://www.googleapis.com/youtube/v3/search?key={{YOUKEY}}&channelId={{CHANNELID}}&part=snippet,id&order=date&maxResults=50&publishedAfter=2014-09-21T00:00:00Z&publishedBefore=2014-09-22T02:00:00Z