The required parameters for 2Checkout as stated in the docs are li_#_type, li_#_name etc. but the 2Checkout Omnipay library doesn't seem to have this functionality.
Is this library just out of date now?
The 2checkout library was written based off of these docs: http://www.2checkout.com/documentation/Advanced_User_Guide.pdf
Which no longer exist, apparently. So yes, the library has become out of date and will need to be rewritten based on the new documentation and required parameters. From what I can tell 2checkout isn't versioning their API, so I'm not able to indicate which version this library addresses.
Related
Recently Google plus is pending for shutdown, which also shutdown some Google Plus API including this one https://www.googleapis.com/plus/v1/people/me which our service is actively using.
That above API was used in one of our legacy login library, which I can't even find the source for it. Hence I am now trying to patch it myself.
Reading the migrate guide from Google, it doens't tell much in terms of how to change the url.
Referencing some open source library like 1, 2. I have come up with the fix of replacing the url https://www.googleapis.com/plus/v1/people/me with https://www.googleapis.com/oauth2/v3/userinfo, which works but oauth2/v3/userinfo lacks documentation, so I am pretty worry that oauth2/v3/userinfo is not intended to be used like the above.
So my question is:
Is my solution: change https://www.googleapis.com/plus/v1/people/me with https://www.googleapis.com/oauth2/v3/userinfo an intended migration, if not then how can I migrate out of Google Plus API?
Any documentation on https://www.googleapis.com/oauth2/v3/userinfo? The closest I can find is this, which seems more like an brief intro then a documentation.
The "/oauth2/v3/userinfo" call will not be deprecated on March 7th, 2019 as it is not part of the Google + API.
If you look at the Google Developers Console, those calls are not registered as part of the Google + API.
From Google email:
If you are directly requesting the “plus.me” scope, any other Google+
OAuth scopes, or making any Google+ API calls, please ensure that you
remove these requests from your project before March 7, 2019.
Since nobody answer, I think I will give out the best info I can gather...
For 1. Supported by multiple open source project. Pac4j, hybridauth. It seems like the method of change https://www.googleapis.com/plus/v1/people/me with https://www.googleapis.com/oauth2/v3/userinfo is the best you can do to fix this issue.
For 2. Still no detail documentation for that
I'm using SAP Success factors API that i found:
I'm sending get request to this host https://user_name.successfactors.eu/sfapi/v1/soap12?wsdl with relevant credentials and i'm getting an XML but without the user version (something like b1808 (for august 2018).
Do you know how can i get this version?
Thanks a lot:)
First of all, SFAPI is deprecated or will be deprecated soon and I personally expect SFAPI to reach "end of life" within the next releases. But that is my personal opinion, officially SAP recommends using OData API but does not restrict using SFAPI: Page 8/9 for Deprecation Info
I am quite familiar with OData API and did not find any version information, I assume this also applies to SFAPI. The assumption relies on the information, that the APIs are always downward-compatible, this means you don't have to develop for a separate version, you could developt against the API no matter of the underlying version of the system.
If you really require to split according to the version of your system you could only separate by your system. This means if you have a two-tier environment, you need to know where you are requesting the API and develop against it. Furthermore systems differ from 3 to 8 weeks, 4 times in a year, but still they are compatible.
Maybe you could describe your goal a little bit in detail, then I might help to find a good solution.
This is the top option available to non-API users when they are editing a survey collector, so someone at SurveyMonkey must have recognized that it is important. However, the API documentation does not mention that capability. Is it actually available but not documented?
This can be achieved by adding the following in the JSON body in the POST request:
"sender_email":"email#address.com"
This is not mentioned in the Knowledge Base as far as I can tell. Working on the Platinum package, so not sure if this will work for other paid subscriptions.
You're right that option should be there. It will be available to add as an option when creating/updating a collector of type email soon.
See the collector docs https://developer.surveymonkey.com/api/v3/#surveys-id-collectors or watch the docs on github (https://github.com/SurveyMonkey/public_api_docs) to be notified of when the change has been made.
I am using Swagger Editor to generate YAML/JSON code that will display the details of my API in Swagger UI.
I would like for the consumers of my API to be able to view a revision history (ex. an added field, a field changed from 'optional' to 'required', etc) of the API document. Is this functionality supported by Swagger?
Now it's possible with swagger-diff
As far as I know it is not supported, at least in swagger-ui itself
While an interesting idea, this is a hard problem to solve. Please check out this feature request - https://github.com/swagger-api/swagger-spec/issues/233. Feel free to add comments and opinions to help push it forward.
is there an api call to get the latest version of the api?
something like:
https://rally1.rallydev.com/slm/webservice/versions
i have read through the documentation at:
https://rally1.rallydev.com/slm/doc/webservice/
but have not spotted anything like this.
all the urls have the version embedded in them, so it's like a chicken and egg thing.
Current version of API cannot be determined programmatically.
In WS API 1.18 we deprecated "current" pointer to the most recent version of the web service.It changed with every new release of the web service. We deprecated it because it was found to negate the benefits of the web service versioning. Users tended to point at current as a convenience without being prepared for its intrinsic volatility. To encourage users to point their applications at a specific version and to minimize the impact of releasing new versions of web service API we removed the current pointer altogether.
The most reliable way to check the latest version of API is to access our WS API doc you mentioned in your post.
There you can see the latest version under the Available Versions section in the left frame. The latest one is by default listed as selected.