I'm using the latest version of fullcalender 4 in an angular 7 project. Fullcalendar 3 used ajax to request json feeds for the events, but version 4 relies on SuperAgent, so a lot of commands were renamed or removed. One of them being "headers: {}". Since its not a public Calendar, i need to send a jwt token, but i cant find a smart way to do that, besides adding it to the request url. Is the headers feature just renamed and i dont find the docs to use it, especially since SuperAgent makes sending headers super easy, or is it not supported (yet)?
Related
I have an web API application that will serve many clients at different times of release and now i need to implement a versioning. Because the API code will be constantly updated and API users will not be able to instantly change their API. Well, the standard situation is when you need to introduce versioning in general. I'm finding a way to organize it inside my API. It's clear that it will not be different folders with an application on the server, conditionally called app_v1, app_v2, app_v2.1, etc., cause this is duplication, redundancy and bad practise.
It's look like will be one application, and in the controllers at the code level there will be a division of the logic already, like If(client_version==1) do function1() else if(client_version==2) do function2(), etc. It seems that git supports tags, this is something similar to versioning, but because all supported versions of the application need be on the server at the same time, this is not about that. how i can realize an architecture in this case?
There are many well-known ways to use API versioning to make code work with older versions. (backward compatibility). The general purpose of API versioning is a way to make sure that different clients can use different versions of an API at the same time. I've seen several ways to do API versioning, such as:
URL Path Versioning: In this method, the number of the version is part of the API endpoint's URL path. For instance:
https://api.example.com/v1/assets
https://api.example.com/v2/assets
URL Query String Parameter: In this method, the version number is added to the API endpoint's URL as a query string parameter. For instance:
https://api.example.com/assets?version=1
https://api.example.com/assets?version=2
HTTP Header: In this method, the version number is put in an HTTP header, like the Accept-Version header. For instance:
Accept-Version: 1
Accept-Version: 2
If you are using dotnet for you project I would like recommend to standard library for that recommend to check this out. Or you can find solid materials in term of WebApi Versioning following link by #Steve Smith.
There is another answer.
Google sent me a reminder to migrate from Dialogflow API v1 to v2. I don't use Dialogflow. The skill is connected to custom Python code on our own servers. Our code gets JSON and returns JSON. Should I be concerned?
What you've described still could be using Dialogflow, since Actions using Dialogflow can also be written in Python and receive JSON.
Some things that might be indicators:
If you have an actions.json file, and deploy this when you update your Action, you are probably not using Dialogflow.
If the JSON you receive contains an attribute "result" or "originalRequest" (or both), then you're using Dialogflow's fulfillment webhook protocol.
If you're looking at inputs[0].intent to see what Intent was triggered, and the value either matches one in your actions.json or a string such as actions.intent.TEXT, then you're using the Actions SDK and not Dialogflow.
If you were looking at result.metadata.intentName to get the name of the Intent, then you're using Dialogflow.
If you are using Dialogflow, you need to move to v2, which will require some changes in the names of several of the JSON fields. https://dialogflow.com/docs/reference/v1-v2-migration-guide-fulfillment#webhook_request_and_response_json (and sections further down on the page) provide information on the changes and what you'll need to do.
Yes! you should be concerned, I have faced the same issue as JSON has been changed for somethings already.
Our LinkedIn API calls started failing. Even the simplest /v1/prople/~ calls started erroring with This resource is no longer available under v1 APIs.
So we're trying to migrate stuff using the new /v2 way, but somehow it seems not to be working. For example (and after requesting a token with the new scopes), a simple request to /v2/me fails to return the fields we need (amongst others, headline and location). When asking explicitly for these fields, we're told that we don't have access to them - even tho the token was generated using the r_basicprofile r_liteprofile r_emailaddress scopes.
We've tried numerous combinations and variations of asking for certain fields, projections, formats, etc from the Microsoft docs - with no avail and we're wondering whether the /v2 API is actually something functional - is there anyone successful using it, and if so, how?
A sample CURL request with an obfuscated Bearer would be a good way for us to understand what we're doing wrong - but it seems that even the simplest requests verbatim from the docs just fail.
EDIT: After some research, it looks like Microsoft changed their versioned API behavior without being consistent in the docs. Some docs point to r_liteprofile and some others to r_basicprofile as the default way to go now without being "Linkedin Partners". We were previously requesting r_emailaddress too and the headline and location parts of the r_basicprofile bits were used in our code in many different places.
These were two problems:
Some of the fields are removed from v1 (headline, email, location etc),
Most of the fields requested are not available in v2 without special scopes, but these scopes are very poorly documented as being part of a "LinkedIn Partner" program our app has to be accepted in before we can now use them.
The basic answer to this question is that LinkedIn (Microsoft) made backward-incompatible changes to their API.
I've got a problem: I'm working on an external webinterface for my company and we use Atlassians JIRA as a project issue and tracking method. I am trying to connect our webinterface over the REST API. After a short research I found out, that Atlassian never implemented the possibility to create a new JIRA Project over their REST API. Well, that isn't that true, they've implemented it in the actual version (7.0) because they migrated their other two APIs to one REST API. Now comes my problem: We are currently unable to upgrade from version 6.4.4 to version 7.0.0. After a second search I found a workaround for this problem. You can find it here:
The real problem is that this workaround isn't working or I'm doing it wrong.
I've already tried it with a GET request and the given arguments as parameters and over the normal POST method with a JSON body in it.
What's my problem?
Here some more informations: When I try it over GET, I always receive the normal response for the URL (it returns a list with all available templates). When I try it over POST with a JSON body (this is by the way the normal method for the normal functions of the REST API) I get back a HTTP-Error 415 Unsupported media type.
it would be nice if someone could test this workaround with a 6.0+ version of JIRA
So after some months I got it by myself. You have to make a POST request with the following header fields:
Content-Type=application/x-www-form-urlencoded; charset=UTF-8
Authorization=Basic {set your credentials as a Base64-String: "user:password"}
X-Atlassian-Token=nocheck
Once done you can set your POST-Parameters to the following:
name=Name of the Project
key=Key of the Project
lead=Leader of the Project
keyEdited=true (don't change it!)
projectTemplateWebItemKey=com.atlassian.jira-legacy-project-templates:jira-blank-item (don't change it!)
projectTemplateModuleKey=com.atlassian.jira-legacy-project-templates:jira-blank-item (don't change it!)
Hope that this helps someone, Jira is just weird in some cases :/
I have been using the Google Client API in a .NET web application - but need to update to the latest version (both to use the most recent code but also to lose the need for the DotNetOpenAuth.dll.) The latest version (1.8.1) has a totally redesigned OAuth interface (using google.apis.auth) and I can't seem to even get started w/ it.
Previously I had written code that handled generating an AuthorizationURL (as needed) and creating IAuthenticator and IAuthorizationState objects - storing the refresh token in a sql database as needed. I was also about to retrieve "UserInfo" about the user as needed (once authenticated.)
Now - I'm unclear on how to handle the generation of the AuthURL (do I have to do it 100% manually?) and how/what I need to pass to the BaseClientService.Initializer when working w/ client API (such as Google Drive.)
Also - previously I wrote methods to "store" and "retrieve" credentials from the database - now it seems I would need to write a class based on IDataStore? But I'm not sure if this is even correct (let alone find a decent sample/doc anywhere.)
Finally - it doesn't seem like google.apis.auth handles anything w/ regards to UserInfo - I have to grab google.apis.oauth2 - but that .dll has even LESS documentation/sample code out there.
Any advice on where to start? The google.apis sample code seems decent for performing basic api tasks but all the Oauth2 information is very basic, uses file data storage and seems glossed over.
Thanks!
First of all, take a look at https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth. All the documentation that you might need is there, and if something is missing let us know!
You are right, you already have an implementation of FileDataStore, and we are planning to create EFDataStore as well for the next release.