We use Google APIs Calendar v3 and Google said that they'll discontinuing support for json rpc Discontinuing support for JSON-RPC and Global HTTP Batch Endpoints.
I cant find if they plan a v4 version compliant or if the current version is compliant. Documentation don't reference about it. Java Quickstart
Any information about that?
Its not just Calendar that is effected its all Google APIs discovery APIs that are effected. The batching endpoint
POST /batch HTTP/1.1
Authorization: Bearer your_auth_token
Host: www.googleapis.com
Content-Type: multipart/mixed; boundary=batch_foobarbaz
Content-Length: total_content_length
Will be discontinued around March 25, 2019. That being said i am skeptical that the client libraries have all been updated to remove it already. I am a contributor on two of them and haven't heard anything yet about removing the the batching ability from the libraries.
Google API Client Libraries have been regenerated to no longer make
requests to the global HTTP batch endpoint. Clients using these
libraries must upgrade to the latest version. Clients not using the
Google API Client Libraries and/or making custom calls to the JSON-RPC
endpoint or HTTP batch endpoint will need to make the changes outlined
below.
The global batching endpoint is
www.googleapis.com/batch
the new one is
www.googleapis.com/batch/<api>/<version>
I think the choice of words incorrect here and it they will be regenerated if needed. The change should not effect users with one exception. That being heterogeneous batch requests a single batch request containing more then one API within the call wont work due to the fact that the end point is API specific.
Now for the bad news to my knowledge there is nothing that is going to be replacing it. You will not be able to make heterogeneous batch requests. The Google apis java client library appears to use the old endpoint BatchRequest.java so if you are using heterogeneous batching your going to have to change your code by the time they update the library to support the new API specific endpoint.
Update
After a lot of back and forth with Google over the last 24 hours I have gotten some clarification on that post.
Batching will still work with the client libries
Most of the client libraries appear to already use this endpoint so there should be no change.
You will only be able to call one API within a batch request. Example you cant call drive and calendar API in the same batch request. You will have to make two batch requests one for drive and one for calendar.
There may be some edits coming to that post to clear up the language a little to be more clear.
I have updated my answer to reflect the clarifications from Google
It is not removing batching entirely.
Per the blog they are removing heterogeneous batching - accessing the same API with requests that lead to other APIs. They are also consolidating homogeneous batching (batching to the same API and leading to a singular API) to "API specific batch endpoints".
From my understanding of the blog, if you are batching several different requests, ie. a Foo request and a Bar request into a Foo API call, you will have to adjust your code to use one batch for one and one batch for the other. If you are already doing that, it is unclear whether or not you will have to change your code, perhaps newly released libraries will have a new way to handle these requests.
Related
Re golang YouTube API, I would like to know what calls to perform to make a slate image appear in the middle of a livestream. Reading the API documentation here, it's suggested that the "control" operation is used to achieve this, however, this operation is not supported by the API in the latest version. I did find this functionality in a prior version (v0.3.2); why would this have been removed and what is the replacement ?
Cheers,
Saxon
The API behavior you're experiencing is documented officially, as per this excerpt from the official specification of the liveBroadcasts.control API endpoint:
Note: The liveBroadcasts.control method has been deprecated and will stop working on or after 1 October 2020. After that date, all calls to this method will return a forbidden (403) error, and the method will later be completely removed.
Clients can still implement their own slating by adding an overlay to the video sent to YouTube’s ingestion servers. See deprecation announcement.
There's nothing you can do about that, but only to file a feature request directly to Google in the attempt to make the company reinstate the feature that it retracted from the current API.
In my opinion (which is based on the experience of several years of monitoring the SO tags youtube-api, youtube-data-api and youtube-livestreaming-api), waiting for Google to respond to you here on SO is waste of time. Just do what I already recommended you to do in my comments posted under your question above: reach out directly to Google (through the company's official issue tracker site) for to obtain official accounts from the company's staff.
in my Laravel 5.7/mysql app I need to make external api to read some data from external
app with get request and to write some data to my db with post request.
Which tools/scripts are there for this and how to make these requests safe?
MODIFIED :
Thanks for feedbacks, but looks like I badly put my question
The external app(I do not know what is it written with) need to read data from my app
and write data to my Laravel 5 app.
And how have I to test these requests while on development locally ?
Looks like I have to use Guzzle as in provided link?
Which steps have I to take for safety on my side?
Thanks!
These three libraries are popular for your use-case:
Guzzle
Curl
zttp
If the database is local you can use Eloquent, If not, remote connection to that database may help. otherwise, if you only have API access you should consume eighter of above libraries or any alternative options to make an HTTP request your application might require.
Security-wise, as long as you are only making a request to a remote server, the Suggested way is to store any key or secret string related to authorizing your request (if applicable) in your .env to prevent it from committed to your version control systems. Needless to say to always handle any possible HTTP error your remote API might throw in order to prevent any unwanted error on your application side.
And as Abir Adak mentioned in the comment check this thread for further details.
Updated Answer: On the case of MODIFIED part, generally you have 3 popular options,
REST API
This blog post is a detailed walkthrough written for Laravel
This one from Stack Overflow can help you with designing you API
This last one can help you to develop a widely accepted API response and endpoints by following its specifications.
GraphQL
Can save some time for developing your API, but I suggest to make sure that the consumers of your API are happy to use this option.
GraphQ
Laravel Package for GraphQL
If using Laravel isn't a must, and you are using PostgreSQL, you might want to look at Hasura as well.
SOAP
Have little knowledge on this option for Laravel, just know folks coding using C# and .net are happier to expose their API with this protocol. read more about it on WikiPedia
Postman is a great tool for testing your API or any other API.
Currently, I have been tasked to utilize the Google People API to ask for a user's basic Google information along with their public phone numbers. So far the results have been positive.
The solution my team and I have incorporated the Google People API integration in has the capacity to be utilized across thousands of domains. As a result, my question is simply, How can my team members and I ensure that any our clients that utilize our solution with their own particular domain get our new functionality built with the Google People API?
Keep in mind, our clients have the flexibility to have http/https and any subdomain on their site. Entering each domain possibility for our client base one by one would not be an easy task. I'm seriously hoping there is a solution around the single, explicit origin entries.
Thank you for your time and help.
Warning:
You must remember that if this is source code you are giving your clients that you are not allowed to release your client id and client secret. This includes plugins and scripts.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
So if your clients could view the code of your application and see your client id and secret you should not be giving it to them.
Read more about this issue Can I really not ship open source with Client ID?
Recommendation:
The best solution for you will be to instruct your users now to create there own project on Google Developer Console and create their own JS origins.
You may just have to provide your own wrapper around the target API where you authorize the client request yourself and then do the request from Google using your own credentials.
Do I need to send individual entity updates to WebAPI, or can I POST an array of them and send them all at once? It seems like a dumb question, but I can't find anything that says one way or another.
Brad has a blog post that talks about implementing batching support in Web API.
Also, Web API samples project on codeplex has a sample for doing batching in web API hosted on asp.net.
It seems like WEB API 2 has support for this
From the site (Web API Request Batching):
Request batching is a useful way of minimizing the number of messages
that are passed between the client and the server. This reduces
network traffic and provides a smoother, less chatty user interface.
This feature will enable Web API users to batch multiple HTTP requests
and send them as a single HTTP request.
There are a number of samples for different scenarios on this page.
https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching
You will have to create an action that accepts a collection of items.
If all you have is an action that accepts a single item than you need to send separate requests.
With batching always think about how you would report the failures and whether a failing of a single item should invalidate the whole batch.
I am trying to make a web app using ExpressJS and Coffeescript that pulls data from Amazon, LastFM, and Bing's web API's.
Users can request data such as the prices for a specific album from a specific band, upcoming concert times and locations for a band, etc... stuff like that.
My question is: should I make these API calls client-side using jQuery and getJSON or should they be server-side? I've done client-side requests; how would I even make an API call from the server side?
I just want to know what the best practice is, and also if someone could point me in the right direction for making server-side API requests, that would be very helpful.
Thanks!
There's are two key considerations for this question:
Do calls incur any data access? Are the results just going to be written to the screen?
How & where do you plan to handle errors? How do you handle throttling?
Item #2 is really important here because web services go down all of the time for a whole host of reasons. Your calls to Bing, Amazon & Last FM will fail probably 1% or 0.1% of the time (based on my experiences here).
To make requests users server-side JS you probably want to take a look at the Request package on NPM.
It's often good to abstract away your storage and dependent services to isolate changes and offer a consolidated and consistent web api for your application. But sometimes, if you have a good hypermedia web api (RESTful responses link to other resources), you could reference a resource link from another service in the response from your service (ex: SO request could reference gravatar image/resource of user). There's no one size fits all - it depends on whether you want to encapsulate the dependency or integrate with it.
It might be beneficial to make the web-api requests from your service exposed via expressjs as your own web-apis.
Making http web-api requests is easy from node. Here's another SO post covering that:
HTTP GET Request in Node.js Express
well, the way you describe it I think you may want to fetch data from amazon, lastfm and so on, process it with node, save it in your database and provide your own api.
you can use node's http.request() to fetch the data and build your own rest api with express.js