Question
Is it possible to get rates for all possible ups services in the same request?
Background
Although the UPS rates documentation states that the service element is optional
Requests with the service element defined respond successfully while requests without the element defined result in the following error:
["Error"]=>
array(3) {
["ErrorSeverity"]=>
string(4) "Hard"
["ErrorCode"]=>
string(6) "111100"
["ErrorDescription"]=>
string(58) "The requested service is invalid from the selected origin."
}
Additionally, every example and library i've seen either only desired to create requests for one type of service or creates a request for each service the user specifies they want to receive:
// optional, you can specify which rates to look for -- performs multiple requests, so be careful not to do too many
In Summary
Is there a way to return rates for all services from UPS that I am missing or must we query UPS for each service we wish to get a rate for?
You should be able to receive rates for multiple services by setting the /RateRequest/Request/RequestOption to Shop and omitting the /RateRequest/Shipment/Service element.
This is outlined in UPS's documentation for the Rate Webservice endpoints:
Can a customer compare services for a shipment using the Rating API?
Yes. Use the “Shop” value, instead of the “Rate” value, in the RequestOption element of the ../Request container to retrieve the rates for all services for the stated lane pair. The API response will return a rate for each of the available services. This is known as the Shop option.
Related
in Shopify
Dawn theme,
I want to display the minimum and maximum delivery date on page checkout.liquid, using CarrierService (Shopify API).
I need to get min_delivery_date and max_delivery_date. And the problem is that I make a request for - /admin/api/2022-01/carrier_services.json, and I get a response that doesn't have min_delivery_date and max_delivery_date.
I get this response:
{
"carrier_services":[
{
"id":57492111453,
"name":"dhl_express",
"active":true,
"service_discovery":true,
"carrier_service_type":"legacy"
},
{
"id":57492144221,
"name":"ups_shipping",
"active":true,
"service_discovery":true,
"carrier_service_type":"legacy"
},
{
"id":57492078685,
"name":"usps",
"active":true,
"service_discovery":true,
"carrier_service_type":"legacy"
}
]
}
Question: Why are the values min_delivery_date and max_delivery_date not displayed?
I can't understand why this is happening.
Please help.
You are asking Shopify to give you a list of carrier services, and it is responding correctly. You are seeing three, DHL, UPS and USPS. Asking Shopify for a list of carrier services has nothing to do with checkout, and a request made to a Carrier Service.
If you wanted to know the delivery dates of a shipping rate response, you'd have to be inspecting the response from the carrier services! And that is not something you get to do. Instead, you get to form the responses themselves when you deploy your carrier services in your own App.
So clearly, if you are interested in min/max delivery dates, open up the code in the App you installed, and discover why no dates are being provided. Also, note that playing with the min/max delivery dates in response is tricky stuff! It requires a deep understanding of business days, weekends, and the results you respond with to get it right.
I'm looking into how to use the Time Sheet Invoicing Upload and first port of call was the Try It Out page.
The documentation lists the value for the mandatory "Type" field as TIMESHEET INVOICING but this seems at odds with other calls (it's usually just the call name, e.g. Time Sheet Invoicing Upload). Have tried these values and multiple other variants on the "Try It Out" page but all have failed so far with "The Type value specified in this file is not recognized".
Grateful for any pointers on how to get this working and/or advice on whether the SAP Fieldglass REST API documentation for this call might need to be amended.
As an aside - am also wondering about some of the fields listed in the body - e.g. TIMESHEET ID and ORIGINAL TIMESHEET ID are in block capitals, which doesn't follow the convention of other fields and the API reference for this call just has "data": [ {} ] in the body with no actual fields present - again, this is at odds with other calls.
Re: Main question - The documentation is incorrect - the Type value should be "Time Sheet Invoicing Upload". Also found out that this particular call can only be made by a Supplier tenant, not a Buyer tenant. In our case, we needed to request SAP to enable Configuration Manager for that tenant and then we could log in as the Supplier, change to the linked Configuration Manager account, create the API Application Key and License Key, enable the integration connector and use all of the above to authenticate as the Supplier and make the API call... it also requires a Buyer field in the header (set to the 4 digit Buyer code e.g. "A123") - this also isn't mentioned in the documentation.
Re: Aside - Turns out the API is case insensitive for field names - e.g. "Timesheet ID" will work just as well as "TIMESHEET ID".
Best(Standard) practice to send multiple parameters to REST get resource - Spring
What's the best practice to send multiple parameters on a REST GET resource call. Normally we can call GET call with path param &/ query. what is the best practice on how to achieve this(second and third).
Ex: /user/{username}/locaction} - Its a standard way
2. /user/{username}/{locaction}/{mobile_umber} - is it a standard way?
3. /user/{username}/{locaction}/{mobile_umber}/{age} - is it a standard way?
In terms of URLs, params tend to be more like RPC where you're invoking a function, e.g.:
/user?username=123
which is more like a traditional RPC call:
Object user = GetUsername(123);
REST represents a state of a resource which can be made up of many "states". Core information such as personal info, where 123 is the username:
/user/123 -> {"name":"Joe Bloggs"}
some aspects of the state of the user could change over time:
/user/123/location -> {"username":"123",lat:123456,lon:54568}
aspects of the user that are unlikely to change rapidly could be included in the core info /user/123 or if they're unlikely to be needed by a client, they can be requested separately:
/user/123/mobile -> {"username":"123",mobile:"345345"}
A User has a location and a User has a mobile and a User has an age. A location doesn't have a mobile or age so those aspects would never come under /user/location. They would come under the URL that represents the object that does have them:
/user/123/age -> {"username":"123", "age":100}
A location can have an accuracy which can either be requested separately:
/user/123/location/accuracy {"accuracy":"-1"}
or more likely included in the response to /user/123/location.
So the REST structure in this case mirrors the object hierarchy, the has parts.
The REST structure could also mirror the business structure:
/user/account
/user/contactinfo
/user/location
it just depends how you want to expose the data that represents a User and their states.
I'm finalizing a Data Studio connector and noticing some odd behavior with the number of API calls.
Where I'm expecting to see a single API call, I'm seeing multiple calls.
In my apps script I'm keeping a simple tally which increments by 1 every url fetch and that is giving me the correct number I expect to see with getData().
However, in my API monitoring logs (using Runscope) I'm seeing multiple API requests for the same endpoint, and varying numbers for different endpoints in a single getData() call (they should all be the same). E.g.
I can't post the code here (client project) but it's substantially the same framework as the Data Connector code on Google's docs. I have caching and backoff implemented.
Looking for any ideas or if anyone has experienced something similar?
Thanks
Per the this reference, GDS will also perform semantic type detection if you aren't explicitly defining this property for your fields. If the query is semantic type detection, the request will feature sampleExtraction: true
When Data Studio executes the getData function of a community connector for the purpose of semantic detection, the incoming request will contain a sampleExtraction property which will be set to true.
If the GDS report includes multiple widgets with different dimensions/metrics configuration then GDS might fire multiple getData calls for each of them.
Kind of a late answer but this might help others who are facing the same problem.
The widgets / search filters attached to a graph issue getData calls of their own. If your custom adapter is built to retrieve data via API calls from third party services, data which is agnostic to the request.fields property sent forward by GDS => then these API calls are multiplied by N+1 (where N = the amout of widgets / search filters your report is implementing).
I could not find an official solution for this either, so I invented a workaround using cache.
The graph's request for getData (typically requesting more fields than the Search Filters) will be the only one allowed to query the API Endpoint. Before starting to do so it will store a key in the cache "cache_{hashOfReportParameters}_building" => true.
if (enableCache) {
cache.putString("cache_{hashOfReportParameters}_building", 'true');
Logger.log("Cache is being built...");
}
It will retrieve API responses, paginating in a look, and buffer the results.
Once it finished it will delete the cache key "cache_{hashOfReportParameters}building", and will cache the final merged results it buffered so far inside "cache{hashOfReportParameters}_final".
When it comes to filters, they also invoke: getData but typically with only up to 3 requested fields. First thing we want to do is make sure they cannot start executing prior to the primary getData call... so we add a little bit of a delay for things that might be the search filters / widgets that are after the same data set:
if (enableCache) {
var countRequestedFields = requestedFields.asArray().length;
Logger.log("Total Requested fields: " + countRequestedFields);
if (countRequestedFields <= 3) {
Logger.log('This seams to be a search filters.');
Utilities.sleep(1000);
}
}
After that we compute a hash on all of the moving parts of the report (date range, plus all of the other parameters you have set up that could influence the data retrieved form your API endpoints):
Now the best part, as long as the main graph is still building the cache, we make these getData calls wait:
while (cache.getString('cache_{hashOfReportParameters}_building') === 'true') {
Logger.log('A similar request is already executing, please wait...');
Utilities.sleep(2000);
}
After this loop we attempt to retrieve the contents of "cache_{hashOfReportParameters}_final" -- and in case we fail, its always a good idea to have a backup plan - which would be to allow it to traverse the API again. We have encountered ~ 2% error rate retrieving data we cached...
With the cached result (or buffered API responses), you just transform your response as per the schema GDS needs (which differs between graphs and filters).
As you start implementing this, you`ll notice yet another problem... Google Cache is limited to max 100KB per key. There is however no limit on the amount of keys you can cache... and fortunately others have encountered similar needs in the past and have come up with a smart solution of splitting up one big chunk you need cached into multiple cache keys, and gluing them back together into one object when retrieving is necessary.
See: https://github.com/lwbuck01/GASs/blob/b5885e34335d531e00f8d45be4205980d91d976a/EnhancedCacheService/EnhancedCache.gs
I cannot share the final solution we have implemented with you as it is too specific to a client - but I hope that this will at least give you a good idea on how to approach the problem.
Caching the full API result is a good idea in general to avoid round trips and server load for no good reason if near-realtime is good enough for your needs.
I want to get domain authority value from "moz.com" (didn't find other sources).
Sometimes page does not load properly and response from moz.com does not have proper dom elements which I parse. Probably page uses javascript to show values. It also has restriction, can not analyze more than 3 times/day (I need to visit it maximum once a day)
require 'rest-client'
require 'nokogiri'
link_url = "http://google.com"
api_url = "http://moz.com/researchtools/ose/links?site="
response = RestClient.get(api_url + link_url.split("?").first)
value = Nokogiri::HTML(response).css('.url-metrics-authority span.large').first.text.strip #previously there was Nokogiri::HTML(response).css('.metrics-authority').first.text.strip
pp value
From console that works good, but when I run it using ruby script, it fails.
Can I somehow wait for js to execute or are there any other sources to get domain authority?
You can get the Domain authority for any website/URL by making use of the free URL Metrics API provided by Moz. You will need AccessId and Secret key to consume Mozscape API's. I would suggest you to build a wrapper API to get Moz Domain Authority around the Moz API so that you can consume the wrapper API from the Javascript.
I am Russ Jones and consult for Moz. I also helped architect the latest version of Domain Authority.
The appropriate documentation for collecting Domain Authority is here
Getting an API Key is free and allows for 2,500 lookups per month at no faster than 1 every 10 seconds. Paid access starts at $250/mo and includes 120,000 rows per month with significantly fewer restrictions.