Linkedin api v2 implementation

[leventeolahx]

Hi SandRock,

I would like to contribute on implementing Linkedin api v2. Do you have any concept on your mind how we should start it?

As i saw in Linkedin documentation there are quite major changes on return types too (e.g. check firstName field on Profile) not just on endpoints.

I was thinking to change/ add the xml. Maybe we will need to add an extra xml level to support for return types. And also need some modification how to generate the code.
For dynamic fields like firsName (on Profile) we could simply use JObject (or this needs more rethinking).

Cheers,
Levente

[sandrock]

Hi,

Here a few info I gathered... You can go to the conclusion down below.

---

API changes analysis

API V2 home

LinkedIn's v2 REST APIs differ in some ways from the v1 APIs, and also introduce some new concepts to the RESTful API world.

(Thank you LinkedIn for this great description of your new API)

Error handling

The new return message for error has changed from:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<error>
  <status>401</status>
  <timestamp>1304550749494</timestamp>
  <error-code>0</error-code>
  <message>[unauthorized]. No consumer found for key 11iK9RUZ1FLJaLUpp90xztjhJXLkdTooiNqXMAORUrpoWJaR0cozd863qyIwvb0ZJ</message>
</error>

to:

{
  "status": 401,
  "serviceErrorCode": 401,
  "message": "Empty oauth2_access_token"
}

Not a big deal to change.

I see the app permissions are the same.

Authentication

Seems like nothing has changed for OAuth.

General

About REST methods it looks like somebody invented REST again. Yeepee.

The API is JSON only now.

Few more info: protocol info

URNs & IDs

URNs are a new concept in LinkedIn's v2 API used to represent foreign associations to an entity (persons, organizations, etc.). A URN is a string-based identifier that takes the format: urn:{namespace}:{entityType}:{id}

They created something funny. Again. Should not be too hard to implement.

More docs: Common URNs & Namespaces, RFC 2141

Fields

They changed the way fields works. That is not very nice.

Decorations

That is quite surprising.

Paged responses

New pagination arguments.

Peoples APIs

I see many changes in the data structures. Localization. Fields.

Organizations and Brands

Many changes.

Share and Social Stream

Many changes. Very obscure (just as before).

---

Conclusion

They made too many changes in the API.

• The code generation cannot work for the new API
• New patterns and funny things must be coded
• Operations are the same but everything works quite differently

The big ways:

• We can create the new endpoints with new code in this project to have compatibility with both V1 and V2 APIs
• Or we can abandon this project and start a new one

I will not be able to support those changes. This library is getting old by the way. I think the community should start anew with a clean project with support for dotnet core.

Thank you everyone for your support 👍

If any new project starts and gets support, please post the link here so I can reference it.

[leventeolahx]

Hi Sandrock,

Meanwhile I started to change the project to use v2 so I took your project and rewrote the xml and some stuffs to support linkedin api v2. Currently only some endpoints are supported like basic person, company and share api.

Pushed the changes to the forked project:
https://github.com/247GradLabs/LinkedInNET/

[sandrock]

Ok. Cool. 👍

You should try to keep the V1 code untouched in order to have a library that is able to use both APIs.

I recommend to duplicate the code generation thingy and make it work for V2.

[sandrock]

I'm planning to archive this repository.

If you have any request about the README or nuget package, here is the final call.

Should a I publish a final nuget containing incentive to switch to another project?

Is there any fork I should promote in the README?