Where can I find a guide for complete UPS Shipment JSON developer guide for shipment?
I know that they have a pdf guide for shipment, but I think not all fields are present on their JSON Developer pdf guide. Like the field number of package is missing. And is there a field where you can put the package value like 100 USD.
And It's not well explained. :(
UPS uses the same query structure everywhere.
The description of all fields is in the "Shipping Package Web Service Developer Guide.pdf". To use JSON, you just need to send a request to the URL specified in the "Shipping Package JSON Developer Guide.pdf".
Related
We have on-premise TFS Version 15.105.25910.0 i.e TFS 2017 and I am trying to get JSON data (let's say for a given Work Item id). I am using Postman to send/receive request. I was having an issue with permission denied then figured out a way to pass Personal access tokens in the request.
Our basic TFS Url looks like this:
http://tfs.blahblah.org:8080/TFS/MyOrgName/Software%20Group
How to correctly get JSON data?
Reference material used:
Reference 1
Reference 2
Currently I am getting 200 OK status but the content type is HTML which says Javascript is Disabled. Not sure where the problem is occuring?
Feel free to ask more info if needed.
First, you are using TFS 2017 RTM version, it's suggested to upgrade to the latest Update 3.1 edition.
Then, please check your Postman's version, make sure you are using the latest version v6.1.4. You could download the latest version from website below: https://www.getpostman.com/
Last, check whether you have correct api. The REST API to get a single work item is as below:
Get http://TFS2017:8080/tfs/DefaultCollection/_apis/wit/workitems/{id}?api-version=3.2
Attach a screenshot of the result in Postman:
I use the the TFS Builds in my application and was wondering if there is a documentary for the json response which i get from the TFS API. Especially for the field "AuthoredBy".
Here an example of the response json.
Yes there is documentation (https://www.visualstudio.com/en-us/docs/integrate/extensions/reference/client/api/tfs/build/contracts/builddefinitionreference) but it is not kept up to date, is incomplete and wrong on many instances unfortunately :(
Edit: i noticed the link i posted at that time now forwards to a different api... here is the updated link -> https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds?view=azure-devops-rest-5.0
I'm learning how to use a third party API called Wunderground and I don't know how to request, receive, and use their results which is in a Json format.
If you see their website a developer can sign up for free and receives an API KEY. You can then request weather data in the following URL format.. http://api.wunderground.com/api/KEY/FEATURE/[FEATURE…]/[SETTING…]/q/QUERY.FORMAT
So I have tried it in my web browser by typing some parameters and I received a very long Json file with the correct information (I checked). Problem is I don't have the slightest idea of how to create a variable which can make this request, and even if I was able to do that I don't know where should I receive the file and how to get only the results I want (in this case current weather).
You have to use Titanium.Network.HTTPClient to make request.
For code examples related to Json parsing you can use:
Appcelerator: Using JSON to Build a Twitter Client
HTTPClient()
Please provide me some references to call WebScripts in alfresco remotely using JSON..
Alfresco has some default Webscripts ,I need to invoke these Webscripts in different Application remotely...
There is no documentation that I know of at the present time that documents all web scripts that expect JSON to be posted along with a schema that defines the expected JSON. Honestly, we haven't done a good job identifying which out-of-the-box URLs are actually public. Some are there just for the Share application's use and could change without warning.
With that said, you can go to http://localhost:8080/alfresco/s/index and see a list of web scripts. And if you drill down into the web script (click on the web script's ID), you can see the source code for the JavaScript controller or, if the web script is implemented in Java, you can see the full class name that implements it. You can then inspect the source to see what it is expecting.
Another way to do it is to use Firebug or your browser's developer console to watch the network calls that go from your browser to the repository tier. Many of these calls include JSON being posted to repository tier web scripts.
Assuming you're referring to getting a webscript to respond with a json, there are a few steps.
1. Create a webscript, and possibly set json the default format (in the webscript definition file, i.e. mywebscript.get.desc.xml, add a tag
<format default="json">argument</format>
Create a JSON controller too, ie. mywebscript.get.json.js. This script can do two things:
a) get json parameter (if you sent a json in): if (json.has('myparam')) myVar = json.get('myparam');
b) provide some data to the model, ie. model.docs = companyhome.children
Your webscript also needs to format this json for json response, i.e. mywebscript.get.json.ftl would look something like this:
{ "docs": [
<#list docs as doc> {
"name": "${doc.name}",
"prop": "${doc.properties["mymodel:myprop"]}"
} <#if doc_has_next>,</#if>
</#list>
]
}
I am developing a REST API for my web application for public use.
I am tempted to provide only JSON as format for the response as it is more lightweight than XML (on large traffic, any byte counts).
I think any programming language and platform is able to easily and effectively parse JSON, nowadays.
So, what do you think about providing only JSON and not XML as format for the response?
Thanks,
Dan
Some quantitative data on XML vs JSON here:
http://www.slideshare.net/jmusser/pw-glue-conmay2010
(see slide 11)
From the 2,000 API's they checked, 45% of them supported JSON in 2010 and the numbers we're quite quickly rising. With a total of 132 (of those 2,000) that only accept JSON. No statements we're made about the amount of XML-only API's.
That's pretty much how I work all the time. I found that Google Chrome displays JSON responses out-of-the-box, while XML responses require me to "view source" or cheat using Content-Type: text/plain. I also find JSON very handy when building command-line mini-tools to interact with web/comet servers, message buses, etc., because there is so much less typing and the typing you have to do is so much easier. For instance try timing yourself as you type this on the command line:
sendmsg foobar/queue1 '<msg><labels><rows><row>a</row><row>b</row><row>c</row><row>d</row><row>e</row></rows></labels></msg>'
vs. this:
sendmsg foobar/queue1 '{"labels":["a", "b", "c", "d", "e"]}'