Where can I find godaddy customerId in UUIDv4 for certificates api? I need customerId to retrieve my certificates list but there is no information in godaddy docs where to find this one.
Go to your profile > view source code > find "customerId" tag > done.
In my case, doing a GoDaddy Certificates integration for a customer, I only had the customer's API key and secret key available, but I still needed the UUIDv4 customerId.
I used a GET request to the v1/certificates endpoint to get the shopperId from inside one of the certificate metadata objects, then another GET request to v1/shoppers/{shopperId}?includes=customerId.
The response to the Shoppers API request provided the UUIDv4 customerId value, which finally allowed me to use the v2/customers/{customerId}/certificates endpoint.
For anyone who might be stuck with this:
You can use this endpoint v1/shoppers/{shopperId}?includes=customerId
And simply use your customer number (available on top left corner of page under your profile name) as shopperId - that was not obvious to me.
This is just an extension to Mark Miller's comment, visualising what to expect and how the complete API call looks like (customerId is the last returned key-value pair; 12345678 in API call is your shopperId which you can find in GoDaddy's control panel):
https://api.godaddy.com/v1/shoppers/12345678?includes=customerId
{
"shopperId": "12345678",
"marketId": "en-GB",
"email": “your#email.com",
"externalId": null,
"nameFirst": “Your”,
"nameLast": “Name”,
"customerId": “X-X-X-X-X”
}
Related
I want to integrate shopware in my application and I have a problem with the api.
I used dockware.io solution to get started with shopware and create a demo store. I was able to create customers and products and place orders.
But while I request the order through the API, I am not able to get lineItems of the order, it is always null. I have the same problem with the deliveries attribute. Here is a screenshot of the response to my request.
Why am I not receiving the items in the reply? Is there any other request I can make to receive them?
You need to add the lineItems association in the request body of your API request. Same for the deliveries association and so on.
{
"associations": {
"lineItems": [],
"deliveries": []
}
}
I'm trying to get a PUBG player's details using the Players developer API.
I'm aware that both the operations of this Players API require the account ID of the respective player, whose account details are required.
However, I tried my best to find the account ID (starting with account. and having 32 alphanumeric characters), but all in vain.
In this aspect, I've two specific questions:
How can I find my PUBG account ID?
If I want to fetch other players' details via API, how do I get their account ID programmatically? Or should I need to ask for their account ID explicitly?
Use filter[playerNames]=myPlayerName as shown in the player docs
On succes, it wil return a object containing the account_id;
https://api.pubg.com/shards/steam/players?filter[playerNames]=myPlayerName
{
"data": [
{
"type": "player",
"id": "account.c0e511111111111893af",
...
Replace myPlayerName with the username you're looking for.
edit;
This Community Manager says that only - and _ are allowed in nicknames, url-escaping won't be necessary!
I'm attempting to get a list of recent transactions/orders from the Square Connect API V2 that lists out exactly what was purchased.
I tried the suggestion posted here:
How to retrieve Square orderIds for Call to BatchRetrieveORders
and received the error "Provided merchant_id and merchant_id in authorization do not match up."
I also attempted "v2/locations/(locationID)/orders/batch-retrieve" and received the error:
{
"success": false,
"message": {
"resource_bundle_name": "com.squareup.webservice.WebserviceMessages",
"key": "there.was.a.problem.processing.this.request",
"arguments": []
},
"debug_info": ""
}
I am able to get a list of transactions, but it isn't useful to me without the item information.
I'm using a personal account with the Personal Access Token.
This looks like a well-handled error in terms of its messaging. I suspect that the error message is telling you what you need to know. From this post, a Square employee mentioned that the cause is likely that you are:
using OAuth credentials for one merchant but attempting to retrieve data for another merchant. For example, if you have OAuth tokens for merchant A with location B but try to list payments for location token X that belongs to a different merchant Y, you will get this error.
You should validate that the token you're using is correct for the merchant you're trying to retrieve data for. If you're certain it's correct, I'd reach out to Square directly as there may be an issue with this token.
Suppose my model is:
User:
id
nickname
I have a collection /users/
I want the Users to be retrieved by /users/{id} and not /users/${nickname}, because in some more complex cases, there could be no "logical unique constraint".
So the basic JSON payload I could use is for exemple:
{
id: 123,
nickname: 'someUserName'
}
Nothing fancy here.
POST on /users/
As far as I know, an user as an identifier. It is part of the resource representation, so it should be in the payload (?).
Put what if I want to generate the ID myself on the backend, using a DB sequence for exemple?
Then my payload becomes:
{
nickname: 'someUserName'
}
Is this appropriate?
What is supposed to be the output of this POST? Nothing? Just a header referencing the resource location, including the ID?
GET on /users/id
When we get the resource, we load its content as JSON:
{
id: 123,
nickname: 'someUserName'
}
PUT on /users/id
As far as I know, the payload used on this method is supposed to "override" the resource content. If we wanted partial updates, we would have used PATCH.
But what if I do:
PUT /users/123
{
id: 456,
nickname: 'someUserName'
}
Does this mean that we want to update the id of a resource?
Isn't it kind of redundant to use the id in both the URI and the payload?
Actually I don't really know how to handle the id.
I don't know if I am supposed to use the same resource representation in all POST / PUT / DELETE operations.
I don't know if the id should be part of the unique(?) resource representation.
But if the id is not part of the representation, then when I list the users, using GET /users/, if the ids are not returned, then I don't know how the client can get the user ids...
Can someone help me? :)
First of all
It is not REST if you don't use HATEOAS
I hope you understand this, I'll come back to that at the very end.
POST on /users/
It perfectly ok to not use an ID in the POST payload. If an ID is present react with an error message, so developers understand they are doing wrong.
Therefore only the nickname as a payload is perfectly valid if you don't have anything else in your user resource
The output of your server should include three important things:
HEADER: A status code indicating success or failure (usually 201 Created)
HEADER: The location of the newly created resource (just Location: /path/to/resource)
BODY: A representation of the created resource. Give back a complete payload like on a GET!
GET
perfectly valid
PUT
your analysis regarding PUT/PATCH matchs the spec, the new resource should be identical to the payload meaning the user wishes to change the id if it differs. if a payload contains values which shouldn't be changed (like the ID) you have two possibilities:
Ignore the ID in the payload
Return an error
In both cases inform the user about what you did and what went wrong. I prefer to send/get a 400 Bad Request. If a privileged user could change the ID but the particular user can't an 403 Forbidden may be more appropriate.
Also make sure to document your APIs behaviour. You may allow the ID to be omitted in your API. Don't forget to treat IDs given in a POST payload in a consistent way!
Overall questions
REST operates over Resources.
/users/ is an example for an collection of resources
/users/{id} is an example for a single resource
You should always use the exact same representation in each and every response. If for some reason it is more appropriate to give only a snippet of the information add metadata (link) pointing to the full resource representation.
The ID is always present except in the first POST request of an user.
POST implies that the future location of the resource is not known and has to be provided by the server.
This also means that GET /users/ should return the IDs for each resource.
As always in APIs return strict and be forgiving in requests. document your behaviour so users can learn.
HATEOAS
The true beauty of REST comes to daylight if you implement HATEOAS (Hypermedia As The Engine Of Application State). Part of this means that you should sugar your representations with useful tag/link combinations. This way clients never have to construct an url anymore.
An Example using HAL for your user representation would be:
{
"_links:" {
"self": { "href": "http://yourrest/users/123" }
},
"id": "123"
"nickname": "someUserName"
}
A nice wrapup of using HAL was written by Matthew Weier O'Phinney in his blog when he developed a ZF2 REST Module (first entry is completly zf free, only explaining HAL).
I'm interpreting your descriptions as saying that the id is not part of the resource, it's a unique identifier of the resource. In that case, it should not be part of the payload for any operation.
POST /users with payload {"nickname": "somebody"} would create a new resource with a URL returned in the Location header. That URL would presumably look like /users/123 but from the client's point of view there's no reason to expect that. It could look like /something/else/entirely.
GET /users/123 would (assuming that URL was returned by an earlier POST) return the payload {"nickname": "somebody"}.
PUT /users/123 would (with the same assumption as above) replace the resource with the payload you send with the PUT, say {"nickname": "somebody else"}.
If you want the client to be able to name a resource, then you'd also let PUT /users/123 create a new resource with that URL.
I know of no common RESTful way to rename a resource. I suppose a POST with the old URL as part of the query part or the body would make sense.
Now, suppose I'm wrong and you do want id to be part of the resource itself. Then every payload would include it. But from the client's point of view, there should be no assumption that "id": 123 implies that the URL would be /users/123.
Finally, all of this is from a fairly purist point of view. There is value to thinking of URLs as the only real identifier of a resource, but it's not awful to break that rule and have the client use logic to create the URLs.
Question
How do I return different results for the same resource?
Details
I have been searching for some time now about the proper way to build a RESTful API. Tons of great information out there. Now I am actually trying to apply this to my website and have run into a few snags. I found a few suggestions that said to base the resources on your database as a starting point, considering your database should be structured decently. Here is my scenario:
My Site:
Here is a little information about my website and the purpose of the API
We are creating a site that allows people to play games. The API is supposed to allow other developers to build their own games and use our backend to collect user information and store it.
Scenario 1:
We have a players database that stores all player data. A developer needs to select this data based on either a user_id (person who owns the player data) or a game_id (the game that collected the data).
Resource
http://site.com/api/players
Issue:
If the developer calls my resource using GET they will receive a list of players. Since there are multiple developers using this system they must specify some ID by which to select all the players. This is where I find a problem. I want the developer to be able to specify two kinds of ID's. They can select all players by user_id or by game_id.
How do you handle this?
Do I need two separate resources?
Lets say you have a controller name 'Players', then you'll have 2 methods:
function user_get(){
//get id from request and do something
}
function game_get(){
//get id from request and do something
}
now the url will look like: http://site.com/api/players/user/333, http://site.com/api/players/game/333
player is the controller.
user/game are the action
If you use phil sturgeon's framework, you'll do that but the url will look like:
http://site.com/api/players/user/id/333, http://site.com/api/players/game/id/333
and then you get the id using : $this->get('id');
You can limit the results by specifying querystring parameters, i.e:
http://site.com/api/players?id=123
http://site.com/api/players?name=Paolo
use phil's REST Server library: https://github.com/philsturgeon/codeigniter-restserver
I use this library in a product environment using oauth, and api key generation. You would create a api controller, and define methods for each of the requests you want. In my case i created an entirely seperate codeigniter instance and just wrote my models as i needed them.
You can also use this REST library to insert data, its all in his documentation..
Here is a video Phil threw together on the basics back in 2011..
http://philsturgeon.co.uk/blog/2011/03/video-set-up-a-rest-api-with-codeigniter
It should go noted, that RESTful URLs mean using plural/singular wording e.g; player = singular, players = all or more than one, games|game etc..
this will allow you to do things like this in your controller
//users method_get is the http req type.. you could use post, or put as well.
public function players_get(){
//query db for players, pass back data
}
Your API Request URL would be something like:
http://api.example.com/players/format/[csv|json|xml|html|php]
this would return a json object of all the users based on your query in your model.
OR
public function player_get($id = false, $game = false){
//if $game_id isset, search by game_id
//query db for a specific player, pass back data
}
Your API Request URL would be something like:
http://api.example.com/player/game/1/format/[csv|json|xml|html|php]
OR
public function playerGames_get($id){
//query db for a specific players games based on $userid
}
Your API Request URL would be something like:
http://api.example.com/playerGames/1/format/[csv|json|xml|html|php]