I'm contacting the API of my client's store on BigCommerce. I've verified the option set has a bunch of rules associated with it (8 product rules).
When I contact the api with
/api/v2/products/181/rules I get a 204 response.
This seems to be an incorrect response.
I tried then contacting
/api/v2/products/181/rules/count
and I get a response of:
{ count:0 }
How do I get a proper representation of these rules, as the API specification describes?
Thanks for any help you can provide. I'm stuck.
The response indicates that there are no rules associated with the product ID in your request. Are you sure that the option set you're referring to has been assigned to the product ID referenced in your request? It is possible that the option set has rules but the product does not have an option set assigned to it.
Related
I am attempting to create a single opening balances record against an existing employee but keep getting a 400 Bad Request response with this detail...
At least one NZ opening balance item is required in the request
I am following the instructions as per this documentation...
https://developer.xero.com/documentation/api/payrollnz/employeeopeningbalances#post-opening-balances
URL : {DestinationID} is properly replaced with the employee GUIDhttps://api.xero.com/payroll.xro/2.0/employees/{DestinationID}/openingBalances
JSON Body[{"periodEndDate":"2011-01-30T00:00:00","daysPaid":5.00,"unpaidWeeks":0.00,"grossEarnings":1442.31}]
The Xero forums and support is pretty unreliable so I'm posting here in the hopes for a better response.
After some trial and error using the API Explorer that Xero provides I was able to get it working using their example....
I eventually learned that daysPaid and unpaidWeeks must both be integer whole numbers or else it fails.... The error message provided is misleading but this resolves the problem.
I'm trying to understand which Http Status Code to use in the following use case
The user tries to do a GET on an endpoint with an input ID.
The requested data is not available in the database.
Should the service send back:
404 - Not Found
As the data is NOT FOUND in the database
400 - Bad Request
As the data in the input request is not valid or present in the db
200 - OK with null response
200 - OK with an error message
In this case we can use a standard error message, with a contract that spans across all the 200 OK responses (like below).
BaseResponse {
Errors [{
Message: "Data Not Found"
}],
Response: null
}
Which is the right (or standard) approach to follow?
Thanks in advance.
Which is the right (or standard) approach to follow?
If you are following the REST API Architecture, you should follow these guidelines:
400 The request could not be understood by the server due to incorrect syntax. The client SHOULD NOT repeat the request without modifications.
It means that you received a bad request data, like an ID in alphanumeric format when you want only numeric IDs. Typically it refers to bad input formats or security checks (like an input array with a maxLength)
404 The server can not find the requested resource.
The ID format is valid and you can't find the resource in the data source.
If you don't follow any standard architecture, you should define how you want to manage these cases and share your thought with the team and customers.
In many legacy applications, an HTTP status 200 with errors field is very common since very-old clients were not so good to manage errors.
My application with a HTTP API provides some resources that are identified by name. So, the URLs are constructed as the following:
/path/to/resources/<name>
For example:
/path/to/resources/my_resource
The resources can be updated with PUT operations. It is also allowed to rename a resource with such an update.
PUT /path/to/resources/my_resource
{"name": "new_name", <other properties>}
Response:
HTTP/1.1 204 No content
As a result, the updated resource is now accessible under a new URL:
GET /path/to/resources/new_name
Response:
HTTP/1.1 200 OK
{"name": "new_name", <other properties>}
The old URL is no longer valid:
GET /path/to/resources/my_resource
Response:
HTTP/1.1 404 Not found
Is such behavior correct? Should the PUT operation return the Location header with a new URL? Is it OK to return the Location header with the 204 No content status?
After writing this question I found another, quite similar: REST API Design : Is it ok to change the resource identifier during a PUT call?
The accepted answer was that it is allowed, but not recommended. Still don't know what about the Location header, though.
By changing a resource identifier, I understand you are deleting a resource and creating a new one. So, the approach you described in the question is basically a delete operation using the wrong HTTP verb.
According to the RFC 7231, the current reference for HTTP/1.1, PUT requests are used to create or replace a resource:
4.3.4. PUT
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload.
[...]
If the target resource does not have a current representation and the
PUT successfully creates one, then the origin server MUST inform the
user agent by sending a 201 (Created) response. If the target
resource does have a current representation and that representation
is successfully modified in accordance with the state of the enclosed
representation, then the origin server MUST send either a 200 (OK) or
a 204 (No Content) response to indicate successful completion of the
request.
[...]
I would do the following when the resource identifier needs to be changed:
Perform a DELETE in the existing resource. The response would be a 204 indicating the request was fulfilled.
Perform a POST or PUT to create the resource using the new identifier. The response would be a 201 indicating the resource was created. The response would contain a Location header indicating where the resource is located.
To replace the state of the target resource (keeping the resource identifier), perform a PUT and return a 204 to indicate the operation succeeded.
I don't know about your requirements, but I wouldn't allow the user to change or create the identifier of a resource. I would assume the resource identifier is immutable and should be generated by the application (UUID, of example) or an identifier generated by the database.
I agree with Cássio Mazzochi Molin's answer. However the question is theoretical one, whether renaming the resource really changes the 'identity' of a resource.
For example if a person's name changes, that does not change who the person is. I still would like the URI I previously got for the "same" person to work, even after the name change.
So I guess my point is not to include non-identity related information into the URI. Include an Id number or similar content-unrelated information.
Don't do a DELETE and PUT to another URI (don't relocate the resource) if the identity of the object did not change.
For some deliveries I require a signature which is an extra charge. I would like to know what that extra charge is, using the rate request API. I'd like to know if this is the place to get that value or if there is some other way.
In the documentation, I only see the SignatureOption element in the explanation for the RateReplyDetails, but nothing for how to send it to them in the RateRequest. The replies always say "SERVICE_DEFAULT" for the SignatureOption with a value of zero. I would like the reply to come back with, for example, INDIRECT and some dollar amount. Other options for this are ADULT, DIRECT, NO_SIGNATURE_REQUIRED, etc.
Below you can see where I tried putting the element under the RequestedShipment element. But that causes the reply to be an "invalid element" error. I tried it in various places in the RateRequest to no avail.
<ns:RateRequest xmlns:ns="http://fedex.com/ws/rate/v7" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns:WebAuthenticationDetail>
<ns:UserCredential>
<ns:Key>00000</ns:Key>
<ns:Password>00000</ns:Password>
</ns:UserCredential>
</ns:WebAuthenticationDetail>
<ns:ClientDetail>
<ns:AccountNumber>00000</ns:AccountNumber>
<ns:MeterNumber>00000</ns:MeterNumber>
</ns:ClientDetail>
<ns:Version>
<ns:ServiceId>crs</ns:ServiceId>
<ns:Major>7</ns:Major>
<ns:Intermediate>0</ns:Intermediate>
<ns:Minor>0</ns:Minor>
</ns:Version>
<ns:RequestedShipment>
<ns:SignatureOption>INDIRECT</ns:SignatureOption>
<ns:ShipTimestamp>#DateFormat(Now(),'yyyy-mm-dd')#T#TimeFormat(Now(),'hh:mm:ss')#</ns:ShipTimestamp>
<ns:DropoffType>REGULAR_PICKUP</ns:DropoffType>
<ns:PackagingType>YOUR_PACKAGING</ns:PackagingType>
When using more recent versions of the API you need to set the option inside of RequestedPackageLineItems. Only send the element when you've got an actual signature option selection.
<RequestedPackageLineItems>
… dim, weight, etc…
<SpecialServicesRequested>
<SpecialServiceTypes>SIGNATURE_OPTION</SpecialServiceTypes>
<SignatureOptionDetail>
<OptionType>DIRECT|INDIRECT|ADULT|NO_SIGNATURE_REQUIRED</OptionType>
</SignatureOptionDetail>
</SpecialServicesRequested>
</RequestedPackageLineItems>
While adnyknas answer is correct, regarding the place you should put it in your XML, please note that the Signature service request only works in the USA:
This is info I got from FedEX tech support:
Signature Require (SR) services are unavailable in most countries. It is for FedEx Express U.S. package services and FedEx Ground U.S. services only in U.S.A. Refer to below restriction from http://www.fedex.com/us/2014rates/surcharges-and-fees.html
I'm implementing a basic service to add usernames to user records in a database. The service first checks if the username exists and if it does returns some value to tell the client that the username is already taken. If the username is available it updates the user record and returns "OK". In this application the client is a native IOS mobile app and the server is node.js. But that shouldn't be relevant to this question.
For this service, what would you recommend I use as my return values? For example, when successful should I return a status code 200? A boolean value? A custom string? Similarly for the unsuccessful condition what would the recommended and customary return value be?
The status 201 is intented to be used when some resource is created. So when your user is created you should set status code 201 and set it to 200 when the same request does an update. Additionally you can return the ID id the created/updated user. IMHO you should keep create and update as separate services.
You can use apporpriate 4xx errors (Refer link) when errors happen. Always keep a status message attribute in your response if your response is XML or JSON. You can set appropriate messages into this and the mobile app can check this message based on the HTTP Status Code you give.
I would return a 201 for the successful condition and a 400 or 409 for the unsuccessful condition.
Hope that helps!
Brandon