I am trying to connect to the paypal but i have some questions with regards to the form data i need to pass, paypal expects it like this
"purchase_units": [
{
"amount": {
"currency_code": "USD",
"value": "100.00"
}
}
]
but the form just passes the amount > currencycode > value
so how can i convert the form scope to this type of data which paypal expects, same is the case with other data if i need to send, this is driving me nuts
What PayPal expects is JSON, which is one of the most common formats for sending data between systems in today's web.
You mentioned a form scope, which must be a coldfusion thing. Are you doing a server or "client-side only" integration? Client-side only is very basic, just spit this HTML/JS out to the browser: https://developer.paypal.com/demo/checkout/#/pattern/client
The server-based version is more involved, you will need to communicate with the PayPal API endpoints directly from your server. There are SDKs and guides for a number of more common server-side languages, which you might find adaptable to your purposes -- see 'Set Up Transaction' and 'Capture Transaction' here: https://developer.paypal.com/docs/checkout/reference/server-integration/
This is a more a long comment than an answer, but here goes. Are you trying to do something like this?
<cfscript>
form.value =4
data = { "purchase_units" : [
{
"amount": {
"currency_code": "USD",
"value": "#form.value#"
}
}
]
}
writedump(serializeJSON(data))
</cfscript>
Live version: https://cffiddle.org/app/file?filepath=c5a0ae3e-e24e-462c-8828-a46da98b9ace/2cea5311-965d-4f9c-af0f-7a0a29563e26/20e07958-06f1-41b2-937c-2c98c819a7a2.cfm
Related
I came across HATEOAS on my researches and was thinking : doesn't HATEOAS multiplicate HTTP requests ?
Let's take the basic customer and order example.
Let's say you want to retrieve an order, the endpoint would be /orders/2
with the following JSON response :
{
"id": 2,
"total": 50.00,
"links": [{
"rel": "customer",
"href": "http://api.domain.com/customer/1
}]
}
Now what if I also need the customer ? Do I have to make another request to /customer/1 ? Doesn't this overload the HTTP traffic ?
Couldn't I get the couple customer + order with a single endpoint like /customers/1/orders/2 ?
Or just send the customer in the /orders/2 JSON response ?
{
"id": 2,
"total": 50.00,
"customer": {
"id": 1,
"name": "Dylan Gauthier"
}
}
What's the benefit(s) of one solution or another ? When do I need one or the other ?
Thanks ! :-)
If the server only supplies the customer and order separately, then you have to make two requests regardless of whether they are following REST or not.
Nothing about REST or its HATEOAS constraint prevents the server from providing both customer and order in the same resource, exactly as you have suggested:
GET /orders/2
{
"id": 2,
"total": 50.00,
"customer": {
"name": "Dylan Gauthier"
}
}
But the customer in that response has no connection to the identifier /customers/1 — the server could combine the two ideas:
{
"id": 2,
"total": 50.00,
"links": [{
"rel": "customer",
"href": "http://api.domain.com/customer/1
}],
"resources": {
"http://api.domain.com/customer/1": {
"name": "Dylan Gauthier"
}
}
}
or better yet, group the links by their relation to the requested resource:
{
"id": 2,
"total": 50.00,
"links": {
"customer": [{
"href": "http://api.domain.com/customer/1"
}]
},
"resources": {
"http://api.domain.com/customer/1": {
"name": "Dylan Gauthier"
}
}
}
Whilst this would make it a bit more work for the client to print the name of the customer (nothing at all taxing, mind), it allows the client to fetch more information about the customer if they want to!
Just to add to Nicholas' answer:
Embedding related resources
Pros: saves you a trip to the server
Cons: While it saves you a trip the first time and may be a few lines of code, you are giving up on caching: if something changes in a related resource (that you embedded) client cache is no more valid, so the client has to make the request again. Of course, assuming you leverage HTTP caching. Which you should...
If you want to go this route, you are better off using something like GraphQL... but wait!
Going "pure" HATEOS
Pros: resources have independent life-cycles; easier to make each (type of) resource evolve without impacting the others. By fully leveraging the cache, overtime, the overall performance is far better.
Cons: more requests (at first access), this might be a little slower on first access; some more code to manage the HATEOS thing...
I personally tend to use the second approach whenever possible.
The classic web analogy:
If it can help, a classic website is just another api that serves html related resources, the client app being the browser itself. If you have ever done some html/css/js, you might want to approach it the same way:
For the given particular website, given its navigation architecture...etc would you rather inline all/part of the css/js (the related resources) in the html pages (the main resource) or not.
Currently, I'm working on new product and making REST API for both - public and internal needs. I started with {json:api} specification and I was pretty happy with it until I faced some questions I cannot find answers to.
According to JSON API specification, every resource MUST contain id.
http://jsonapi.org/format/
Every resource object MUST contain an id member and a type member. The values of the id and type members MUST be strings.
And that's fine in many cases but not all.
Most of our endpoints are about "resources"
If I ask for a "things" collection (http://example.com/things)
{
"data": [{
"type": "things",
"id": "1",
"attributes": {
"title": "first"
},
"links": {
"self": "http://example.com/things/1"
}
}, {
"type": "things",
"id": "1",
"attributes": {
"title": "second"
},
"links": {
"self": "http://example.com/things/2"
}
}]
}
If I ask for a single "things" resource (http://example.com/things/1)
{
"data": {
"type": "things",
"id": "1",
"attributes": {
"title": "first"
},
"links": {
"self": "http://example.com/things/1"
}
}
}
But what to do with endpoints which are not about resources and does not have ID?
For example, in our application, there is an endpoint http://example.com/stats which should return stats of current logged in user. Like
{
"active_things": 23,
"last_login": "2017"
}
There is no id for this "resource" (it's not actually a resource, is it?). Backend just collects some "stats" for logged in user and returns an object of stats. There many endpoints like this in this application, for example, we have Notification center page where the user can change email addresses for different notifications.
So frontend app (single-page-app) first has to get current values and it sends the request to GET http://example.com/notification-settings.
{
"notifications_about_new_thing": "arunas#example.com",
"notification_about_other_thing": "arunas#example.com"
}
And there are many more endpoints like this. The problem is - how to return these responses in JSONAPI format? There is no ID in these endpoints.
And the biggest question is - why nobody else is facing this issue (at least I cannot find any discussion about this)? :D All APIs I ever made has some endpoints which don't have "id".
I have two ideas, first is to fake id, like "id": "doesnt_matter", the second - do not use json-api for these endpoints. But I don't like both of them.
Think RESTfully and everything can (must) be a resource. There is no "logged in" user as there are no sessions in RESTful APIs as they are stateless. There's no session state maintained between REST API invocations, so you have to be explicit about who the user is.
In this case, the resource is the user who has some stats attributes (in the simple case) or perhaps a relationship to a separate stats relationship (more complicated, not shown):
GET /users/1234
{
"data": {
"type": "users",
"id": "1234",
"attributes": {
"name": "etc.",
"active_things": 23,
"last_login": "2017"
}
}
}
I'm no JSON API expert- but it's worth noting that while JSON API is a concrete specification, it is not the same thing as JSON, nor as a REST API. If you don't like its semantics, I agree with commenters who argue, "Don't use it." If you are going to use JSON API, do so in a compliant way, where every response is a resource; every resource has an ID and a type; and additional information is supplied as attributes of the resource.
Toward your question, I'm thinking about something similar where my application returns computation results. Now on the one hand, these are not strictly "resources" and so I've been toying with the idea of returning the raw result as an array (which I believe would be valid JSON, with a caveat), e.g:
[ 47 ]
On the other hand, there is the idea that the results are the results of a computation that the client specified RESTfully, in which case one of the following two cases is likely true:
The same request submitted later is likely to have the same result. This suggests that in fact the result really is a resource.
The same request submitted later is likely to have a different result. This suggests that the client may want to track how results change for various queries, and so at least the query parameters should be part of the response.
In both cases, the response really is a 'result' object, and even though it doesn't have an ID per se, it does have an identity. If nothing else fits, the ID could be the query that generated the response.
This seems RESTful to me. User #n2ygk suggests that this is not correct as regards the JSON API spec, that an ID should simply be a unique ID and not have another semantic interpretation.
I'd love to hear other perspectives.
I'm trying to perform a super-simple call to the PayPal Payments API.
{
"intent":"sale",
"payer": {
"payment_method":"credit_card",
"funding_instruments": {
"credit_card_token": {
"credit_card_id":"CARD-XXXXXXXXXXXXXXXXXXXXXXXX"
}
}
}
}
I've tried adding/removing various parts of the request, and I've had minimal success, but inevitably, I come across an error of "Incoming JSON request does not map to API request MALFORMED_REQUEST".
According to the documentation, these are the only required parameters, but I've tried different funding_instruments, adding payer_info, adding transactions, using credit_card_token and credit_card... nothing seems to work, and the documentation is useless for troubleshooting.
Is there a way to be able to determine WHY this is a malformed request? Most of the documentation I am coming across uses payment_method: paypal instead of credit_card. What are better ways for me to troubleshoot why this request is failing?
There are a few things to consider first. Are you in the US?
if not you will need to consider if your country can use the API. You can find Information of which countries can use the API here https://developer.paypal.com/docs/integration/direct/rest/country-codes/
You might also need to validate your json. I've tested what you have posted here, but you might not be generating the information properly in your app. check the output and make sure that it is valid json--MALFORMED_REQUEST is an indicator that required key/value pairs are missing or that the json is not valid... this website will help you validate the json output https://jsonlint.com/
check your headers carefully to ensure that you have a properly formatted header request header. you can check your headers against the api requirements here https://developer.paypal.com/docs/api/overview/#http-request-headers
paypal notes that they provide an error code as a json string for errors arising in this manner, and that details may or may not be provided in the response. error response codes are in the 400 and 500 ranges and correspond to error messages (these are listed on the headers page given above)
However, given your error message which is not listed i'm going to guess that you are missing required key/value pairs in your json...
paypal says that INTENT AND PAYER OBJECTS ARE REQUIRED, but the example payment that they give lists a great deal of information that your sample json is missing--
among those items are the transaction details which are required...
per paypal's api docs "Include payer, transaction details...
paypal api documentation gives examples of of the required payer and intent objects here https://developer.paypal.com/docs/api/payments/
restrictions are further placed on direct credit card payments: they may only be accepted from the UK or US, and only if the account is payment pro enabled...
options for avoiding this issue are:
1) paypal classic api direct payments--https://developer.paypal.com/docs/classic/paypal-payments-pro/integration-guide/direct-payment/
2) braintree direct: https://www.braintreepayments.com/products/braintree-direct
3) or payflow pro: https://developer.paypal.com/docs/classic/products/payflow
Funding instruments in an array so the request should be something like below.
Transaction is required as that's the only way you will be able to specify what amount you are capturing.
{
"intent":"sale",
"payer": {
"payment_method":"credit_card",
"funding_instruments": [ {
"credit_card_token": {
"credit_card_id":"CARD-27V22453CF057824JLLDIA7Q"
} }
]
},
"transactions": [
{
"amount": {
"total": "30.11",
"currency": "GBP",
"details": {
"subtotal": "30",
"tax": "0.07",
"shipping": "0.03",
"handling_fee": "1.00",
"shipping_discount": "-1.00",
"insurance": "0.01"
}
}
}]
}
Is it possible to have TFS 2017 fetch email from Gmail?
For instance...
I have a ticketing system (OS Ticket) on an external server. I have TFS sitting on a private server and would like to have it pull those tickets that are emailed out from OS Ticket to a Gmail account and create tasks within TFS automatically.
First: If this even remotely possible?
Second: Can it be done?
Third: If it can be done, How, are there any examples or is it something seriously easy?
Your requirement is able to be achieved, but there is not default way. You have to code your solution which should contain two parts:
Filter the emails in ticketing system or in Gmail account. For example, in Gmail, you can filter emails by sender with criteria.from='sender#example.com'(check Managing Filters for more information). You would need to get more help from OS Ticket or Gmail side for this part.
Use TFS REST API to create a work item:
PATCH https://{instance}/DefaultCollection/{project}/_apis/wit/workitems/${workItemTypeName}?api-version={version}
Content-Type: application/json-patch+json
[
{
"op": "add",
"path": { string }
"value": { string or int, depending on the field }
},
{
"op": "add",
"path": "/relations/-",
"value":
{
"rel": { string },
"url": { string },
"attributes":
{
{ name/value pairs }
}
}
}
]
You can buy a product like TeamBox or code your solution using TFS API.
It is not trivial to implement a robust solution (you can see a fullly functioning code example in https://github.com/Microsoft/mail2bug), so you need to add some monitoring on top that everything is running smoothly.
I'd like to use this endpoint to display the calculated fees on my site before taking the user to the paypal site; however, when I query the endpoint with a valid payKey, I receive an internal error.
Endpoint: https://developer.paypal.com/docs/classic/api/adaptive-payments/GetPrePaymentDisclosure_API_Operation/
To generate the payKey, I'm POSTing to svcs.sandbox.paypal.com/AdapativePayments/Pay with the following request body:
{
"actionType":"PAY",
"currencyCode":"USD",
"feesPayer":"SENDER",
"requestEnvelope": { "errorLanguage": "en_US" },
"cancelUrl":"test.com/cancel",
"returnUrl":"test.com/return",
"receiverList": {
"receiver": [
{ "email": "someguy#email.com", "amount": "80.00" }
]
}
}
Any ideas as to what's going on?
Note: I had to edit out the valid URLs because I don't have enough reputation.
For GetPrePaymentDisclosure you must supply senderEmail in the PAY request for it to function.
This is because GetPrePaymentDisclosure is supposed to be used to determine the status of the transaction and see if it is covered by the Remittance Transfer Rule.
From the Documentation: This API is specific for merchants who must support the Consumer Financial Protection Bureau's Remittance Transfer Rule.
It does not work to determine the fees beforehand if it does not hit these rules. As all you will get back is [status] => NON_RTR with no information.
If you would like this functionality outside of RTR transactions you should submit a feature request on PayPal's Technical Support Site