Apex Code Development You need to sign in to do that
Don't have an account?
kodeX How to start learning chatter REST api?
I am trying to understand chatter Rest api from months, I have only understood the flow.
Before coding in any new language, we understand the primitive data types, simple hello world example, use of methods, return types etc.
I am good at Java.
My question is to how to use classes of chatter REST api in Java.
Rest api returns information in JSON/XML format, but how to store such a format in Java made grasping difficult for me.
I have already referred salesforce chatter api documentatn a lot, but i found it complete but at very top level( i.e- they have only given classes and code snippets to follow,post,delete etc)
Where can i get an easy tutorial for implementing chatter rest api applications in Java from scratch??
Hi,
The "Consumer Key" is used to identify your app to Salesforce servers. It is used in the authentication process both for trusted and untrusted clients. The "Consumer Secret" should be kept secret at all times and not provided to untrusted clients. It is not used in all auth flows.
An untrusted client is a client such as a mobile phone or web browser which cannot be trusted to keep the "secret" safe. In this case you should use the "User-Agent Flow": https://login.salesforce.com/help/doc/en/remoteaccess_oauth_user_agent_flow.htm First your client should direct its web browser to https://login.salesforce.com/services/oauth2/authorize, passing in the "consumer key" as the "client_id" parameter and a "response_type" of "token", among other parameters. You must pass in your "callback url" as the "redirect_uri" as well. In this flow you don't need a real URL for the callback url, so you may use https://login.salesforce.com/services/oauth2/success (or
https://test.salesforce.com/services/oauth2/success in the sandbox) for now. Just make sure the value you provide matches the callback URL entry for your "remote access application". At the authorization web page that comes up, the end user will be able to log in and approve access for your app. When they are done and logged in successfully, the web browser will be redirected to a URL of the form "<callback url>#<parameters>". Your client does not have to actually follow this URL. Instead you should intercept this URL and harvest the "access_token" value out of the parameters section, for use in any subsequent calls to the Chatter REST API. The response may also include a "refresh token" which can be used later on to retrieve another access token. For security reasons, you will only be provided with a "refresh token" (which can be cached and used to get a new access token later on) if your callback URL is the "success" URL from above or if it starts with a custom protocol (which could be registered for custom handling on some devices like iPhones).
The sample iOS app shows how to use this flow in code, particularly in the AuthContext class here: https://github.com/cseymourSF/Chatter-API-iOS-Sample/blob/master/Classes/AuthContext.m
Once you have an access token you use it to authorize any HTTP requests by passing in the value "OAuth <access token>" as the value for the HTTP header "Authorization". Never cache an access token in your client. The only value that should be cached is a refresh token.
A trusted client is something like a secure server which can be trusted to keep your secret safe. Here you can use the "Web Server Flow" as outlined here: https://login.salesforce.com/help/doc/en/remoteaccess_oauth_web_server_flow.htm . In this case you again direct the customer to a Salesforce login page, with parameters including the consumer key as the "client_id" parameter the callback url as "redirect_uri" and a "response_type" of "code". When the user has logged in and approved your app, the Salesforce server will redirect them to the redirect_uri, including a "code" parameter. The redirect_uri is expected to be hosted on your own server. When the client makes a request against it, your server should extract the "code" value and pass it in another request to Salesforce to exchange it for an access token.
Hope this helps,
- Chris
All Answers
Hi KodeX,
There are a bunch of different technologies involved in using the Chatter REST API, sorry we don't have a step by step tutorial at this time, hopefully in the new year we'll be able to provide some more tutorials.
The basic workflow of a client is:
- authenticate using OAuth 2
- send HTTP requests, including the authentication code in the HTTP header
- receive JSON or XML responses
- parse or deserialize the JSON or XML response into a useful object
I would recommend reading up on OAuth 2 and making sure you understand the standard and when to use what authentication flows. Once a client is authenticated, all you have to include in your requests is a single HTTP header line with the authentication code. You might want to read up on making HTTP requests in Java, or look into REST libraries for Java. As for XML processing in Java, there is some level of built-in support and probably libraries available. There are a bunch of JSON processing libraries in Java too: http://stackoverflow.com/questions/338586/a-better-java-json-library
Cheers,
- Chris
Thanks a lot Chris for mentioning the flow in a detailed manner.
I have got the "Consumer Key and Consumer Secret" codes.
I know they are useful somewhere in the Oath2 flow,
Only 2 steps remain-
i am confused as to which code between the two to use in the HTTP methods?
i am running a java project through eclipse,
(Chatter asks for Callback URL before displaying the secret codes)
i don't know how can i get a Callback URL for my one, java source code file?
Hi,
The "Consumer Key" is used to identify your app to Salesforce servers. It is used in the authentication process both for trusted and untrusted clients. The "Consumer Secret" should be kept secret at all times and not provided to untrusted clients. It is not used in all auth flows.
An untrusted client is a client such as a mobile phone or web browser which cannot be trusted to keep the "secret" safe. In this case you should use the "User-Agent Flow": https://login.salesforce.com/help/doc/en/remoteaccess_oauth_user_agent_flow.htm First your client should direct its web browser to https://login.salesforce.com/services/oauth2/authorize, passing in the "consumer key" as the "client_id" parameter and a "response_type" of "token", among other parameters. You must pass in your "callback url" as the "redirect_uri" as well. In this flow you don't need a real URL for the callback url, so you may use https://login.salesforce.com/services/oauth2/success (or
https://test.salesforce.com/services/oauth2/success in the sandbox) for now. Just make sure the value you provide matches the callback URL entry for your "remote access application". At the authorization web page that comes up, the end user will be able to log in and approve access for your app. When they are done and logged in successfully, the web browser will be redirected to a URL of the form "<callback url>#<parameters>". Your client does not have to actually follow this URL. Instead you should intercept this URL and harvest the "access_token" value out of the parameters section, for use in any subsequent calls to the Chatter REST API. The response may also include a "refresh token" which can be used later on to retrieve another access token. For security reasons, you will only be provided with a "refresh token" (which can be cached and used to get a new access token later on) if your callback URL is the "success" URL from above or if it starts with a custom protocol (which could be registered for custom handling on some devices like iPhones).
The sample iOS app shows how to use this flow in code, particularly in the AuthContext class here: https://github.com/cseymourSF/Chatter-API-iOS-Sample/blob/master/Classes/AuthContext.m
Once you have an access token you use it to authorize any HTTP requests by passing in the value "OAuth <access token>" as the value for the HTTP header "Authorization". Never cache an access token in your client. The only value that should be cached is a refresh token.
A trusted client is something like a secure server which can be trusted to keep your secret safe. Here you can use the "Web Server Flow" as outlined here: https://login.salesforce.com/help/doc/en/remoteaccess_oauth_web_server_flow.htm . In this case you again direct the customer to a Salesforce login page, with parameters including the consumer key as the "client_id" parameter the callback url as "redirect_uri" and a "response_type" of "code". When the user has logged in and approved your app, the Salesforce server will redirect them to the redirect_uri, including a "code" parameter. The redirect_uri is expected to be hosted on your own server. When the client makes a request against it, your server should extract the "code" value and pass it in another request to Salesforce to exchange it for an access token.
Hope this helps,
- Chris
Chris,
Thanks for a detailed and crystal clear explanation!!
It worked like a miracle! And I now have the access token!!
Merry Christmas and a
Happy New Year too!!!
Hi Chris,
I am developing a portlet which has functionality of Chatter desktop.
Problem:
When I redirect to login page of salesforce and enter my credentials it redirect to redirect_uri
which I don't want as my server has issue if we redirect from outside.
So is there any way to get access_token without redirecting.
Or
Any otherway to resolve this issue.
Hi kodex,
Can you send me the code snippet of oauth and how you are getting access token??