スクロール

HRBC Connect API 開発概要

必要な開発スキル

アプリ開発に必要なスキルの目安は下記の通りです。

  • HTTP、HTTPSを使用したアプリケーション開発スキル
  • XMLを使用したアプリケーション開発スキル
  • 2~3年以上のWeb Serviceの開発経験(どのようなアプリを開発するかにより必要要件は異なります)
  • JAVA、C#、PHPおよびその他プログラミング言語を使用したアプリケーション開発スキル
  • HRBC Connect API Guide(本サイト)の内容を理解する能力
  • HRBCの利用方法、データ構造を理解する能力

 

仕様概要

■RESTful API

APIのInterfaceはRESTをベースに設計されています。

HTTP RequestのGETとPOSTを使用して、各Resourceにアクセスし、読み書きを行うことができます。

通信のデータフォーマットはXMLを使用します。

 

■実行環境

HTTP RESTでのアクセスなので、HTTP Requestを制御できる開発言語であれば自由に選択できます。

実績としては、JAVAとPHPが多いですが、.NET Frameworkでも問題ありません。

アプリを実行するWeb Serverを事前に申請頂き、ポーターズにてアプリ登録しておく必要があります。

事前に登録されたWeb Server以外からの認証は拒否されます。

 

■AuthenticationとAuthorization

認証と権限付与はOAuth2.0ベースのアーキテクチャで構成されています。認証には2つのタイプがあります。

  • Code認証
    HRBCにログインしているユーザーとしてアプリを動作させる方法
  • Code Direct認証
    アプリユーザーを使用してアプリを動作させる方法
    ユーザー操作を伴わないバッチ処理などで使用

 

■HRBCのデータ構造

実際に開発を行ったり、要件定義を行うにはHRBCのデータ構造を理解しておく必要があります。

HRBCのデータは階層構造になっております。

HRBCユーザー向けヘルプに解説を掲載しておりますので、HRBCのデータ構造をご確認ください。

 

■非対応API

APIではデータの削除、添付ファイルの削除はできません。また、現状、削除用APIを開発・公開する予定はございません。

 

利用例

アクセス許可を取得したResource(リソース)に対して、データを取得・登録・更新をすることができます。

アクセスできる情報は次のようなものがあり、以下の例のようなことを実現できます。

  • パーティション情報(Partition)
  • ユーザー情報(User)
  • 項目情報(Field)
  • 選択肢情報(Option)
  • 企業(Client)
  • 企業担当者(Recruiter)
  • JOB(Job)
  • 個人連絡先(Candidate)
  • レジュメ(Resume)
  • 選考プロセス(Process)
  • 添付ファイル(Attachment)

 

例1:JOBをアプリサーバーに取り込む

アプリサーバーからJob APIを呼び出し、対象のJOBデータを抽出できます。

kaihatsugaiyou_1.png

 

例2:キャンディデイトをHRBCに登録

アプリサーバーからCandidate APIを呼び出し、キャンディデイトをHRBCへ登録できます。

kaihatsugaiyou_2.png

 

例3:選考状況を取得する

アプリサーバーからProcess APIを呼び出し、対象の選考プロセスを抽出できます。

kaihatsugaiyou_3.png

 

Request例

例1:JOBの項目情報をすべて取得する

■Request

Method:GET

.../v1/field?partition=1&resource=3&active=-1

URLの最後にあるfieldは、Fieldデータにアクセスすることを示します。

partition=1というパラメータでは、Partition Idが1の領域にあるFieldにアクセスすることを示しています。

resource=3では、アクセスするResourceを指定しており、3はJOBを表します。

active=-1は、使用項目と未使用項目の全てを取得することを示します。

 

■Response

項目の属性情報を含めたリストをXMLで取得することができます。

Response Body

<Field Count="2" Start="0" Total="1234">
 <Item>
  <Field.P_Id>100</Field.P_Id>
  <Field.P_Name>ポジション名</Field.P_Name>
  <Field.P_Type>1</Field.P_Type>
 </Item>
 ...
</Field>

 

例2:日本時間2015年3月25日から31日までに更新された求人情報を取得する

■Request

Method:GET

.../v1/job?partition=1&field=Job.P_Id,Job.P_Position,Job.P_UpdateDate&condition=Job.P_UpdateDate:ge:2015/03/24%2015:00,Job.P_UpdateDate:lt:2015/03/31%2015:00

URLの最後にあるjobは、JOBデータにアクセスすることを示します。

次のpartition=1というパラメータでは、Partition Idが1の領域にあるJOBにアクセスすることを示しています。

condition=の部分で抽出条件として、JOBの更新日(Job.P_UpdateDate)を指定しています。

1つ目の条件で指定されている ge はGreater Than or Equalの略で >= を表します。

2つ目の条件で指定されている lt はLess Thanの略で < を示します。

これら2つの条件を条件式としてあらわすと次のようになります。

  Job.P_UpdateDate >= 2015/03/24 15:00 AND Job.P_UpdateDate < 2015/03/31 15:00

尚、時刻の指定で15:00が指定されていますが、これはHRBC APIでの日付と時刻の指定は全てUTCベースで行う必要があり、日本時間との時差を考慮した指定となっているためです。

 

■Response

次のようなXMLを取得することができます。

Response Body

<Job Start="0" Count="10" Total="2234">
 <Item>
  <Job.P_Id>10001</Job.P_Id>
  <Job.P_Position>Software Development Engineer</Job.P_Position>
  <Job.P_UpdateDate>2015/03/25 21:00:00</Job.P_UpdateDate>
 </Item>
 ...
</Job>

  

例3:個人連絡先Idが10001のレコードの電話番号を更新する

■Request

Method:POST

.../v1/candidate?partition=1

Request Body

<Candidate>
 <Item>
  <Person.P_Id>10001</Person.P_Id>
  <Person.P_Telephone>0123-45-6789</Person.P_Telephone>
 </Item>
</Candidate>

URLの最後にあるcandidateは、個人連絡先データにアクセスすることを示します。

次のpartition=1というパラメータでは、Partition Idが1の領域にある個人連絡先にアクセスすることを示しています。

Request Bodyの<Candidate>タグは、このデータが個人連絡先であることを示します。

次の<Item>は1つのレコードを示すタグになります。

<Item>タグは複数個並べて記述することができるため、一度のRequestで複数レコードを更新することもできます。(最大200件)

<Person.P_Id>は更新対象の個人連絡先のIDで、ここでは10001を指定しています。

<Person.P_Telephone>は電話番号を示しており、0123-45-6789を指定しています。

 

■Response

処理が成功した場合、Response HeaderにHTTP Statusとして200が返り、Status CodeをXMLで取得することができます。

Response Body

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Candidate>
 <Item>
  <Id>10001</Id>
  <Code>0</Code>
 </Item>
</Candidate>

 

実装例

例えば、自社サイトとHRBCを連携する場合、サイトに求人情報を表示するためにどのようにHRBC APIにアクセスするかによって、月間のアクセス回数が大幅に変わってきます。

求人情報検索など、HRBCからデータを取得してアプリ上で表示する処理は、APIアクセス数が多くなる傾向にあります。

できるだけAPIアクセス数が少なくなるように、効率的な処理を実装してください。

※1回のRequestで処理できるレコード数は取得(Read)、登録(Write)ともに200件までです。

 大量データ処理については、200件ずつ区切って処理していく必要があります。

 

例えばサイトの求人検索において、1回のJOB Read Requestで企業情報とJOB情報一緒に取得する場合と、最初にClient Read Requestで企業情報を取得し、その企業に紐づくJOB情報をJOB Read Requestで取得する場合とではRequest回数が変わってきます。

example-dev1.png

 

また、JOB情報を自社サイト上に公開する場合などにおいて、クローリングなどの影響によりユーザーアプリへの外部アクセスが想定以上に集中することがあります。

アクセスの都度HRBC APIを実行する場合、アクセス数増大につながります。

データベーやサーバーのメモリ等へのデータのキャッシュかを行い、キャッシュ化したデータから定期的に情報を取得するなど、パフォーマンスを考慮した設計が必要です。

example-dev2.png

 

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています