I was trying to query the /API/reviews/v1/manage/dev/reviews, but with my authorization, I am getting a 403 error. I am using developer users to query this.
The Comments API can be accessed only through the API client mode. To access the API, you need to obtain authorization from the server. The authorization process consists of API client creation and access token obtaining. For details, please refer to: https://developer.huawei.com/consumer/en/doc/development/AppGallery-connect-Guides/agcapi-getstarted#apiclient
https://developer.huawei.com/consumer/en/doc/development/AppGallery-connect-Guides/agcapi-comments-api-overview
Please find the below domain details:
Domain name for China: connect-api.cloud.huawei.com
Domain name for Germany: connect-api-dre.cloud.huawei.com
Domain name for Singapore: connect-api-dra.cloud.huawei.com
Domain name for Russia: connect-api-drru.cloud.huawei.com
As you’re requesting url, is china domain: https://connect-api.cloud.huawei.com/api/reviews/v1/manage/dev/reviews but all the country you are querying are from Singapore.
For more info, please refer to the guidelines.
https://developer.huawei.com/consumer/en/doc/development/AppGallery-connect-References/agcapi-getreviewdetailinfo
https://developer.huawei.com/consumer/en/doc/development/AppGallery-connect-References/agcapi-getreviews
https://developer.huawei.com/consumer/en/doc/development/AppGallery-connect-Guides/agcapi-reference-countrycode
Related
So I'm working on a small project. It's a REST API that will act as the back-end for a 'buy and sell' website.
At the moment I have two main resources: Users and Ads.
A user can create many ads. Every ad was created by some user.
Could someone verify that the following endpoints follow REST principles and that they make sense? If you don't think they look right please suggest an alternative.
//Users
Create a user - POST /api/users -
user details are passed as json in request body.
Get a user by id - GET /api/users/{user_id}
Get the logged in user - GET /api/users/authenticated_user -
An authentication token is passed in the request header and is used to find the user in the database.
Update the logged in user - PUT /api/users/authenticated_user -
new user details are passed in the request body. An authentication token is passed in the request header and is used to find the user in the database.
Delete the logged in user DELETE /api/users/authenticated_user -
An authentication token is passed in the request header and is used to find the user in the database.
Get an ads user - GET /api/ads/{ad_id}/user
//Ads
Get all ads - GET /api/ads
Create an ad - POST api/ads -
ad details are passed in request body and the user_id of the ad creater is got from the authentication token passed in request header. Would this endpoint make more sense to be something like: /api/users/authenticated_user/ads
Get an ad by id - GET /api/ads/{ad_id}
Update an ad - PUT api/ads/{ad_id} -
ad details are passed in request body and the user_id of the ad creater is got from the authentication token passed in request header to make sure the ad was created by him/her. Would this make more sense to be api/users/authenticated_user/ads/{ad_id}
Delete an ad - DELETE api/ads/{ad_id} -
The user_id of the ad creater is got from the authentication token passed in request header to make sure the ad was created by him/her. Would this make more sense to be api/users/authenticated_user/ads/{ad_id}
Get a users ads by id - GET /api/users/{user_id}/ads
Get logged in users ads - GET /api/users/authenticated_user/ads -
An authentication token is passed in the request header and is used to find the user in the database.
The reason for using the authentication token in some endpoints is because the client doesn't have access to the user_id of the logged in user only the authentication token.
Thankyou, would really appreciate your input.
Could someone verify that the following endpoints follow REST principles and that they make sense?
REST doesn't have "endpoints", it has resources. (Fielding, 2018)
Any identifier that is consistent with the production rules described in RFC 3986 "follows REST principles".
What "REST principles" would tell you to do is to design a web site, with interlinked hypertext documents, and web forms, and to take advantage of the standards that are shared on the web.
But what REST doesn't tell you is what pages should be on your web site, or what spelling conventions should be used for your web pages, or how to bridge the gap between the web site and the interesting business activities in your domain.
Any spelling convention you want to use for your resource identifiers is fine. The machines don't care if the spelling of the identifier matches the semantics of the resource.
Humans tend to prefer human readable identifiers - access logs and browser histories are easier to analyze when you can guess what the resource is from the identifier spelling.
Identifier families that can easily be described by URI templates make a number of mapping chores (like routing) much easier.
And of course, it's really useful if bookmarks remain stable.
When attempting to make calls to the Shop and Data SFCC APIs with a sandbox store, is it the sandbox URL itself that should take the place of "https://hostname:port" in the endpoint URL? It's not super clear from the documentation. My SFCC sandbox URL is in the format "https://XXX-001.sandbox.us01.dx.commercecloud.salesforce.com/on/demandware.store/Sites-Site/" (realm ID redacted here). Using that URL with the format suggested by SFCC's API docs doesn't seem to do the trick, but I'm lost as to what other URL would be used here.
Try using the API Explorer first
With the API Explorer, which is an SFCC-built API client UI. You should modify the URL with your sandbox URL:
URL- If your sandbox URL is https://helloWorld-001.sandbox.us01.dx.commercecloud.salesforce.com/on/demandware.store/Sites-Site/, your OCAPI URL should be https://helloWorld-001.sandbox.us01.dx.commercecloud.salesforce.com/s/-/dw/meta/v1/rest
Account Manager Access Role - You need to ensure that you have the OCAPI Explorer access role in your Account Manager as well, and to the correct realm
Client ID - Ideally, your administrator should assign you with a API Client ID too. Else, use the default client ID for sandboxes (which is, type out 30 'a') and for password as well. NOTE: Do not use this approach for production/dev instances as it is a security vulnerability.
Once you are able to see the APIs showing, you should tinker around with the Version (i.e. 20.2 etc.) and the Site (i.e. RefArch) until you see the desired APIs in API exploerer. If this works, then you should have the necessary access and permissions to access OCAPI
While using integromat.com to try to access GCS I get an error:
enter image description here
The error message might be misleading as the instructed string and sent string are identical:
urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
I'm trying to avoid use of OAuth2. Integromat is not registered as a valid endpoint at Google API backend as I understood that would not be necessary when using server-to-server method.
Anyone available and willing to get a mini-contract to dive in on a shared screen together with me to resolve this one?
Best Regards,
Tomas
PS: this is how the failing step looks like on Integromat. "text 68" includes correctly formatted JWT as requested on Google instructions.
enter image description here
Regarding your issue, you can use Single sign-on (SSO). SSO is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. The cloud identity is free, and it will not incur any charges. For more information, please read this documentation.
Using REST API, sandbox and attempting to get bearer token. Receiving the following error
{"name":"INTERNAL_SERVICE_ERROR","information_link":"https://api.sandbox.paypal.com/docs/api/#INTERNAL_SERVICE_ERROR","debug_id":"5a235c510522b"}
How can I find out what the debug id means?
The 'debug_id' is an internal identifier we can use to pull up the request within PayPal.
You may see our classic API calls refer to this as the 'correlationID'.
Unfortunately I'm not finding anything in our system for this debug_id. Can you log a ticket (www.paypal.com/mts) or email me (address in profile) with details of the call, including your full HTTP request (minus credentials) and the resources you tried to access, as well as the full HTTP response?
I suggest we close this answer as it's not strictly programming-related, but I can continue working on this via mail / ticket with you.
By the way; if you're using the 4111111111111111 credit card: this card number is currently inoperable in the Sandbox environment and may throw 'internal service error' type responses as well. You can use any other card number instead.
I was trying to access a sharepoint 2013 list using REST over HTTPS
I used the following Syntax
https://name.sharepoint.com/sites/siteName/_api/web/lists
But it respond with a error that says Access denied. You do not have permission to perform this action or access this resource
Should i give permission somewhere?what might be wrong with the request?
In the future post this on sharepoint.stackexchange.com bud you will get a faster answer, I only saw this by accident on a google query.
Basically this is by design, it isn't about giving permission only pre authorised accounts will get direct access without authentication and then it is security trimmed after that.
Otherwise you need to authenticate against the api with OAUTH.
The rest api being a massive subject that I cannot possibly cover here I recommend you google:
"using oauth sharepoint rest api"
Some good links are:
http://msdn.microsoft.com/en-gb/library/jj164022.aspx
http://www.sharepointnutsandbolts.com/2013/01/calling-sharepoint-search-using-rest-eg.html
Good luck matey.