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.
Related
Reading through GoDaddy's domains endpoint documentation ( https://developer.godaddy.com/doc/endpoint/domains ) am trying to use GoDaddy's API to update DNSSEC records (DS records to be more precise). Very few examples (found none actually) are out there showing how to actually do that.
The above documentation does seem to mention a "model" called DomainDnssec (same URL as above) which does refer to values and their types that need to be either POST'ed or GET'ed using one of the API URLs but it's not clear to me which one. What is "model" in that context anyway (literally just a description of data types that have to be posted or received using particular API endpoints? this is not clear to me either and documentation is silent about that)?
As much as I do not have an issue with using API in general (all set up and working, together with finding out infamous customerId which most folks confuse with shopperId), I'm having a hard time finding which API call allows interacting with DNSSEC on GoDaddy's API.
I did not try much yet as none of the actions (API calls) within the API domain namespace documentation seems related particularly to DNSSEC.
===an update
It seems that in the Action model (https://developer.godaddy.com/doc/endpoint/domains#/), there is a reference to API calls that do not seem to be documented:
DNSSEC_CREATE - Request to create DNSSEC record for the domain via PATCH /v2/customers/{customerId}/domains/{domain}/dnssecRecords
DNSSEC_DELETE - Request to delete DNSSEC record for the domain via DELETE /v2/customers/{customerId}/domains/{domain}/dnssecRecords
Not sure why this call is not explicitly documented among other v2 API calls. An overlook? Still not sure how to build API calls allowing to update DNSSEC records.
I'm a junior Rails developer and I'm trying to understand the pros/cons between CRUD web apps and REST API's.
I know how to turn a Rails Blog into an API, but I don't understand what advantages there are to doing this.
The main difference I can see is that my url for reading a blog went from this
localhost:3000/blog/1
to this
localhost:3000/api/v1/blog/1
And if I want to create a blog the url went from this
localhost:3000/blog/new
to this
localhost:3000/api/v1/blog
I made the view for the API and the Blog controller look exactly the same.
So the end result is that reading a blog or creating a blog has the exact same UX.
I feel like there is something I am not truly understanding about REST API's.
Can anyone describe a hypothetical situation where a Blog API would be better than a CRUD Blog?
I feel like there is something I am not truly understanding about REST API's.
That's not your fault; there is a lot of misunderstanding about REST API's. The Rails community in particular got confused circa 2005, and I don't know that it was ever straightened out.
localhost:3000/blog/1
localhost:3000/api/v1/blog/1
That's just a change of spelling convention. REST doesn't care what spelling conventions you use for your URI, but if you are using a framework (like Rails) to route HTTP requests to the appropriate implementation, then you want to choose spellings that make the routing easy ("convention over configuration").
localhost:3000/blog/new
localhost:3000/api/v1/blog
This change better aligns a "create" request with the caching semantics of the web. It's often the case that adding a new entry to a blog also changes the blog resource itself (the new entry gets listed in the index, for example). So after a successful create, you would like the client to stop using the old copy of the index and fetch a new one.
HTTP's cache invalidation rules describing invalidation of the target resource after a successful unsafe request, so this:
POST /api/v1/blog
instructs the client to invalidate its previously cached copies of /api/v1/blog (if the response isn't an error). Which is great, because the /api/v1/blog representation has been changed by the addition of the new blog post.
POST /blog/new
has exactly the same semantics (because "uniform interface" -- all resources understand the same messages the same way). Which means that a non error response informs general purpose clients that the /blog/new representation should be invalidated.
And that's probably not useful, because it's /blog, not /blog/new, that was changed when we added a new entry to the blog.
In general: the target-uri doesn't identify the handler of the action, it identifies the document (resources being generalizations of documents) that we are trying to change. That allows us to leverage the caching magic that is built into the web.
I am using the auth0-service and I have observed, that after a user logs in successfully, the callback-url is called with an additional string "#_=_"
How can I turn that off? I have already searched the documentaiton at auth0, but searching for "#_=_" does not yield reasonable results
I even had to escape that string with backslashes here in the SO-editor, because it was beeing interpreted...
Please can you offer more information - what library / SDK are you using? For example, what happens if you use:
https://{{YOUR_TENANT}}.auth0.com/authorize?client_id={{YOUR_CLIENT_ID}}&protocol=oauth2&redirect_uri=https://jwt.io&response_type=token id_token&scope=openid email&nonce=123&state=xyz
Just add https://jwt.io as an allowed callback URL in your client settings from Auth0 dashboard.
Bear in mind that for SPA apps etc, the tokens are returned using URL hash fragments - this is deliberate as only meant for Client side consumption - see here for quick description. Mention this only in case you were confusing correct behaviour?
Here is an excerpt from an assignment I am currently doing:
Build a dummy app that:
Contains a REST API that operates over a single resource.
Contains a Backbone client that consumes that API and can list, show, create, update, and remove that resource.
My understanding was that the term "consume" implies total coverage of the API's exposed ressources. However, the assignment says "consumes that API and can [CRUD] that resource".
Is that sentence redundant or is my understanding of the term wrong?
(Bonus question: why searching Google for this question returns countless language-specific tutorials for "consuming an API" but none explain what the term actually means?).
To consume an API means to basically use any part of it from your application.
Consuming an API here means creating a client which can send requests to the API that you build.
It appears that you need to create and API which can handle Create, retrieve, update and delete (CRUD) of a resource. For instance if your REST api is to create a blog, your API should handle CRUD functions for the object/resource blogpost.
POST - Create a blog post
GET - Retrieve a blog post
PUT - Update a blog post
DELETE - Delete a blog post.
It is about the direction of the app's interaction with API - it either provides an API, or consumes it, so there are providers and consumers of API, and this is just a less general and ambiguous term than 'using'.
Simply consuming an API means using it in your application.
For, e.g., GET request to https://someapi/Users will give you all the users.
You need to request this URL https://someapi/Users to get all the users and then you can use it into your application.
I always think about Albert Einstein's quote of "If you can’t explain it to a six year old, you don’t understand it yourself." when someone asks a question that you might take for granted due to technical experience you have on a subject.
I think the following medium.com article does an excellent job explaining it: How do you explain API to a 5-year-old?
simply means : using the API.
You can do it with HTTP method (GET, POST, PUT, DELETE..) using something like Postman (Tool) or maybe you have a client app/library that calls these methods implicitly.
Graph API is not returning image("picture" attribute) for objects corresponding to community pages, which used to be returned earlier. For example this https://graph.facebook.com/178790412179919 does not have picture attribute whereas the corresponding page has an image.
Also the FQL query done on the "albums" connection for some objects does not have a "cover_pid" attribute for an album corresponding to type "profile", which again used to work earlier.
Does anybody know if anything has changed in Graph API corresponding to this in last couple of weeks (I am fairly confident it used to work earlier in the expected way). I looked through Facebook API release notes but could not find any changes corresponding to this. Please let me know if this not appropriate post for this forum.
https://developers.facebook.com/docs/reference/api/page/
picture is a connection, not an attribute. So ...
https://graph.facebook.com/178790412179919/picture
And as the docs say: Returns a HTTP 302 with the URL of the user's profile picture.
Kinda goofy? Yes, but it works exactly as the docs say it does. I suspect they implemented it this way so it could easily be used in an <IMG> tag.
UPDATE:
It still works via FQL. In your case:
https://api.facebook.com/method/fql.query?query=SELECT+page_id%2C+pic+FROM+page+WHERE+page_id+%3D+178790412179919&format=json
I can confirm that this PREVIOUSLY worked, but NO LONGER works. Facebook have removed the picture connection from Community Pages.
I suspect the reason is that most of these images are pulled from Wikipedia, and there was a licensing / attribution issue.
Unfortunately, Facebook is no longer a reliable source of images for entities (e.g. bands).