So I'm using Jira Rest API, where the user can type their own JQL query and then a table will display tasks. The only problem is my Rest API is very slow, and I think it's due to login before it can access the data. Is there a way to make the Rest API faster?
a simple call which GETs around 20 task results takes up to 17sec, before the user gets the requested information.
the URL can be something like:
https://jirabd.xxx.com/rest/api/latest/search?jql=project%20in%20(BUG%2CFIELDB)%20AND%20component%20in%20(%22Fieldb%20Components%22)%20%22AND%20issuetype%20=%20BUG%20AND%20status%20!=%20%22Closed%22&fields=customfield_10100,customfield_10101,status
I simply just need to know where I might have to look to boost the performance, since I have no clue how/where to start looking.
EDIT
Did some more digging regarding login, and it seems its the way our accounts has been setup in the company. The service account I use for login, takes 17sec to login, where a regular account takes 1-2sec to login, so that's why. Now I just have to figure out why this is the case.
If the issue is login, try keeping the authentication cookie for the next requests:
https://developer.atlassian.com/server/jira/platform/cookie-based-authentication/
or OAuth as they do suggest
Related
I am a bit confused. The requirement is that we need to create a REST API in Salesforce(Apex class) that has one POST method. Right now, I have been testing it with POSTMAN tool in 2 steps:
Making a POST request first with username, password, client_id, client_secret(that are coming from connected app in Salesforce), grant_type to receive access token.
Then I make another POST request in POSTMAN to create a lead in Salesforce, using the access token I received before and the body.
However, the REST API that I have in Salesforce would be called from various different web forms. So once someone fills out the webform, on the backend it would call this REST API in Salesforce and submits lead request.
I am wondering how would that happen since we can't use POSTMAN for that.
Thanks
These "various different web forms" would have to send requests to Salesforce just like Postman does. You'd need two POST calls (one for login, one to call the service you've created). It'll be bit out of your control, you provided the SF code and proven it works, now it's for these website developers to pick it up.
What's exactly your question? There are tons of libraries to connect to SF from Java, Python, .NET, PHP... Or they could hand-craft these HTTP messages, just Google for "PHP HTTP POST" or something...
https://developer.salesforce.com/index.php?title=Getting_Started_with_the_Force.com_Toolkit_for_PHP&oldid=51397
https://github.com/developerforce/Force.com-Toolkit-for-NET
https://pypi.org/project/simple-salesforce/ / https://pypi.org/project/salesforce-python/
Depending how much time they'll have they can:
cache the session id (so they don't call login every time), try to reuse it, call login again only if session id is blank / got "session expired or invalid" error back
try to batch it somehow (do they need to save these Leads to SF asap or in say hourly intervals is OK? How did YOU write the service, accepts 1 lead or list of records?
be smart about storing the credentials to SF (some secure way, not hardcoded). Ideally in a way that it's easy to use the integration against sandbox or production changing just 1 config file or environment variables or something like that
With there being rate limits should I ask for an increase when trying to get all access approval? Since my app asks the driver/ rider to sign in using their uber credentials will this help limit the calls to the API?
Thanks in advance.
Probably not, but it depends entirely on your purpose.
Calls to an API are usually done to get or update data on the home servers, in this case Uber's servers. As such, any Uber specific information you require will likely need to be accessed through their API.
Now, I've not reviewed Uber's API so if you can use the return from the login request to resolve all your needs then great. However, if you need to get data from their servers it would only reduce calls to the API if they require data returned on the login which can only otherwise be retrieved by making another call to their API.
I'm still trying to wrap my head around all this, so my apologies if I've made a mistake, but it seems like the old NVP apps that are now unable to be registered as of December 1st had some features available that can't be replicated in the new REST world order...
Here's what I want/need: I need to be able to translate buyer-side transaction IDs into my seller-side transaction IDs, and I want to be able to do this on a webserver that is secure but I don't want it to have full access to my account, so I'd like fine-grained authz for this server.
It seems like I am a couple days too late to actually get what I want/need. Basically, GetTransactionDetails does exactly what I want (convert buyer to seller transaction IDs, and returns the rest of the transaction information for good measure). And, although I haven't gotten it working, it looks like the Permissions SDK plus an NVP AppID would allow me to have just the TRANSACTION_DETAILS permission on this service which is exactly what I want.
However, as of Friday apparently I can't get an AppID for the classic NVP API? If so, my timing is impeccable.
Trying to figure out how to do this in the REST API has proven difficult. This thread talks about the sale record, which does indeed take a buyer-side transaction ID, but it does not actually translate it into a seller-side one. It does have the custom field, which helps me a little, but I really need the seller-side transaction ID. It looks like maybe the parent_payment URL in the return from the sale might help, but the API started returning PERMISSION_DENIED on me even on previously successful queries so I can't exactly test this right now. And, even if that did work, it seems like the permissions on the REST API are incredibly coarse compared to the Permissions SDK, for example the sale endpoint is under /v1/payments which seems to also include refunds and all kinds of other stuff I don't want exposed. It looks like there's a Transaction Search permission but it's marked beta and it didn't work for querying a sale for me. But maybe it means they're working on it?
What are my options here?
Thanks,
Chris
Okay, so I played around with this for a while, and it seems like the PayPal REST API is just not very good. So, I worked around the limitations here using AWS Lambda and its fine-grained IAM permissions. I created a Lambda function that took my PayPal NVP credentials as encrypted env vars, and an IAM account that could only call my Lambda function, and so now I've got a microservice that will translate transaction IDs and return some extra info (custom and email) from the transaction to boot.
I wish I didn't have to use AWS to work around PayPal's limitations (which seem to be getting worse with the REST API, the NVP api would have been fine if I could have gotten and AppID and used the Permissions SDK), but oh well.
Chris
Actually I have an API called update user data, it is called when the user moves from one page to another page. If the user copy the API from console and post in postman, user should not able to update the user data. How to provide security or implement feature to not to update data through post man.
You really can't.
You can slightly make it harder using some CSRF protection, but that's just it - it will only make it a bit harder, but not stop anyone determined.
If your API is public, you should be ready for your users to have custom client apps.
I am a bit confused by your question. Because PostMan or other applications like Fiddler are created to make the job easier for developers during development. anyhow if you are concern about who makes call to your webpage, you can make your API private and just give access to the user that have the right credentials. You can also read about CSRF or XSS.
I have an application that goes and gets a users messages from their facebook account, but I've hit an error.
The user in question has a thread between him and me in his inbox, however it doesn't show up in his API call to /me/inbox with his specific access_token.
I do have a valid token (it works for all other calls), and I know it should be working fine (I am opening it in my browser directly to debug, and the data just does not exist).
There is no second page to view, no limit or timestamp imposed upon it, just missing data.
For testing, we do have every single API permission offered, so I know it is not a permissions problem.
Does anyone have any idea why this could be happening, and how to fix it?
I was struggling with the same problem. I found that using the `/me/threads' endpoint delivers much more complete data.
Update:
However I found out that this endpoint is not available to non-developers for the time being:
https://developers.facebook.com/docs/reference/api/thread/