RESTful APIにおける基本的な考え方 | NTT Communications Developer Portal
これからシステムにAPIを組み込んでいこうとした場合、まず真っ先に思いつくのがRESTful APIではないでしょうか。なんとなくは分かっているつもりでも、意外といざ実装してみると難しいのがRESTful APIです。今回はその基本的な考えを紹介します。 HTTP/HTTPSアクセス RESTful APIではHTTPまたはHTTPSアクセスが基本になります。ネットワークのプロトコルは他にもたくさんありますが、RESTfulな実装に向くのはHTTP/HTTPSになるでしょう。 HTTPメソッドがアクションを表す GETは取得、POSTは作成、PUT/PATCHは更新、DELETEは削除を表します。 パスがリソースを表す 例えば GET /users/1 であればユーザID=1に対する操作を意味します。 GET /users/1/posts であればユーザID=1の持っているポスト一覧を意味
RESTful APIのURI設計(エンドポイント設計) - Qiita
RESTful APIのリソース設計で述べた通り、何をリソースとするかを決めたらそのリソースを識別するURIを検討する必要がある。 エンドポイントとは何か エンドポイントとはAPIにアクセスするためのURIのこと。例えば、QiitaのAPIで自分の情報を取得する時のエンドポイントは以下となる。 http://qiita.com/api/v2/users/nagaokakenichi 似たような言葉に「エントリポイント」というものがある。エントリポイントとはプログラムやサブルーチンの実行を開始する場所のこと。 Qiita視点で考えると、 http://qiita.com/api/v2/users/nagaokakenichi を参照されることでプログラムが開始されるので、Qiitaからすると上記URIはエントリポイントとなる。 つまり、エンドポイントはAPIにアクセスする側からの、エントリポ
POSTとPUTの使い分け : アジャイル株式会社
GET はもともと副作用がないメソッドとして定義されており、あるURIに対して、何度GETを繰り返してもリソースの状態は変化しない事が保証されています。 DELETE も GET に次いで判りやすいでしょう。一度削除しても、複数回削除しても、削除された状態が変わる事はありません＝べき等 POST と PUT はどうでしょうか？ リソースの新規作成で考える 例えば社員管理システムをRESTful Webサービスで作成する事を考えます。 社員リソースの URI は以下になります。 http://<サーバ名>/employee/<社員番号> 社員リソースの作成には以下のXMLを利用するとします。 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <employee> <firstname>太郎</firstname> <lastnam
【図解】RESTful WebサービスにおけるHTTPステータスコード : アジャイル株式会社
RESTful WebサービスではHTTPステータスコード=処理結果 弊社 アイコン認証Webサービス は、REST方式のWebサービスとして実装されています。 REST方式でない通常のWebアプリケーションでは、通常HTTPステータスコードとしては200(OK)しか返されません。 エラー等の状態を表す場合でもHTTPステータスは200(OK)が返され、画面に表示される内容にエラーを表すメッセージ等を含ませる事によって状態を表現します。 RESTfulなWebサービスを実現する場合には、処理結果はHTTPステータスコードで表現するべきとされています。 理由としては、以下のものがあげられます。 適切なHTTPステータスコードを返さない ( 全部 200 (OK) とかの ) 場合、エンティティの中身を解析しなければ、処理結果が判別できない。 Web標準に従う事で、HTTPステータスコードから
設計スキル : DFD、CRUD、ER図の目的と書き方 | DN-Web64
設計段階でよく利用されるDFD、CRUD、ER図。それぞれ「何のために作成するのか？」「どのように作成するのか？」について紹介します。 そもそも設計書は必要か？ 小規模なソフトウェアの作成であれば簡単なメモ程度の内容で設計を済まし、すぐにテストコード、実処理のコードを書いても良いと思います。設計書よりもきちんと動くソフトウェアのほうが価値があるからです。要求を聞いて、すぐできそうだな(1日でコーディング、テストができそう)と思ったらソフトウェアを作成しユーザに早く評価をもらうことが大事だと思います。設計書を作成すると仕様が変わるたびに書き直す手間もかかるので、要求が頻繁に変わりそうな場合も詳細に作成しないです。 それに対し、規模が大きくてコーディングやテストに何日もかかりそうな場合、時間を確保して設計書を作成します。設計書がないと、一度に複数のことを考えながらコーディングすることになり、バ
第2回 RESTfulなAPIの設計を学ぼう
Web APIといっても、どのようなURLの、どのようなAPIを定義すればよいのか？ RESTfulなHTTPサービスを実装するためのAPIの定義方法の基礎を説明する。 連載目次 本連載は、ASP.NET Web APIを基礎から解説している。前回は、簡単なHello, Worldコードを確認しただけであったが、今回から本格的な実装の解説に入る。 ASP.NET Web APIにおいて、最低限必要になる実装は、「ルーティングの設定」と「APIコントローラの実装」である。今回～次回は、そのうちの「APIコントローラの実装」について解説を行う*1。 開発環境はMicrosoft Visual Studio Express 2012 for Web（Update3）、言語はC#、対象とするASP.NET Web APIのバージョンは1とする*2。 *1 ルーティングの設定については、第4回目で紹
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (1/4)
ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と
［仮想スイッチ設計］物理NICはスイッチへのアップリンク
仮想環境のネットワークで最も特徴的な点は、サーバー上で仮想マシン同士をつなぐ「仮想スイッチ」が稼働していること。仮想環境をうまく運用できるネットワークを作るには、仮想スイッチと物理スイッチの接続方法を理解し、適切なタグVLANを設定しなければならない。 物理サーバーのポートにはタグVLANを設定 仮想スイッチの基本的な役割は、大きく二つある。一つは、仮想サーバーの仮想NICと物理NICを接続して外部のネットワークへとつなぎ込む。もう一つは、1台の物理サーバー上で、仮想マシン同士を接続する役割である。 仮想スイッチに関する設計上のポイントは、VLANの設計にある。特に1台の物理サーバー上で稼働する複数の仮想サーバーに異なるVLANを割り当てて運用する場合、タグVLANを設定する必要がある。 外部の物理スイッチと仮想スイッチをつなぐリンク（物理NICを含む）には、一般的なトランクポートと同様に
大量データのバッチ処理を高速化するHadoop
Hadoopというソフトウエアが、いま注目を集めています。米Googleが発表した論文のアイディアをオープンソース・モデルで実装したソフトウエアです。膨大な量のデータを処理する必要に迫られた企業や研究組織が、続々とHadoopを実際に活用しはじめています。 私たちの研究グループでは、Wikipediaなどの巨大なテキスト・データを解析するために、2007年頃からHadoopを利用しはじめましたが、日本国内でも2009年あたりからHadoopを使った事例を多く見聞きするようになりました。国内で初めてのHadoop関連イベントが2009年11月に東京で開催され、オライリー・ジャパンから2010年1月にHadoop本の邦訳が出版されるなど、Hadoopが多くの開発者の注目を浴びています。 しかしながら、「Hadoopは何となくすごそうなんだけど、複雑だし、どんなソフトなのかいまいち分からないんだ
C＋＋クラス設計に関するノート
C++が他のオブジェクト指向言語と比べて難しいのは、やはりメモリ管理をプログラマが自分でしなければいけない点だと思います。よくよく注意しないと、削除し忘れたり、同じオブジェクトを2度削除してしまうというエラーが発生します。このノートでは、オブジェクトを「値オブジェクト」と「参照オブジェクト」というカテゴリに分け、詳細設計の段階で注意すべき点を整理しておきたいと思います。 0. はじめに 私自身今までいくつかのプログラミング言語を使ってきましたが、C++ が他のオブジェクト指向言語と比べて難しいのは、やはりメモリ管理をプログラマが自分でしなければいけない点だと思います。例えば、 Person* person = new Person(); と生成したオブジェクトは、使い終わったら次のように削除しなければなりません。 delete person; 生成してすぐ削除するなら簡単なのですが、実際に
クラス設計の考え方
ソフトウェアの開発において、クラスの設計は、大切なポイントの１つです。どのようなクラスや関数を作るのか。ソフトウェアのデザインは、それによって決まります。 現在のソフトウェア工学で主流となっているのは、オブジェクト指向の考え方です。開発言語も、C++やJavaといったオブジェクト指向言語が広く使われています。しかし、いくらオブジェクト指向言語を使って開発していても、クラス設計の考え方が誤っていれば、まったくオブジェクト指向的でないソフトウェアができてしまいます。 貴方が、あるちょっとした機能の追加を頼まれたとしましょう。さて、いくつのクラスや関数を作れば良いのでしょうか。また、そのクラスや関数の名前は、どのように付ければ良いのでしょうか。貴方なら、どのように考えを進めて、クラスや関数を設計していきますか？ ここでは、ワイルドカードを使った文字列の検索を例に、クラス設計をする際の考え方を紹介
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTfulとは
基本設計書