アプリ開発の流れを変える「GraphQL」はRESTとどう違うのか比較してみた
注：単純なデータモデルでさえ、今後の維持や説明が必要になる6つものエンドポイントが含まれています。 あなたがクライアント側の開発者で、movies APIを使い、HTMLとjQueryで単純なWebページを作るとします。そのためには、映画と出演俳優・女優の情報が必要です。APIに必要な機能は揃っているので、データを取得します。 新しくターミナルを開いて以下を実行します。 curl localhost:3000/movies 以下の応答が返ってきます。 [ { "href": "http://localhost:3000/movie/1" }, { "href": "http://localhost:3000/movie/2" }, { "href": "http://localhost:3000/movie/3" }, { "href": "http://localhost:3000/mo
Swagger、GraphQL、gRPC+Protocol Buffersの概観 - Qiita
この記事について この記事は、DroidKaigi2018の以下の発表に刺激を受けて書いた記事です。 まだAPI定義管理で消耗してるの？〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜 すばらしきGraphQLのSEKAIへようこそ gRPCとProtocol Buffersで一味違うAndroid通信 上記の発表では、Swagger、GraphQL、gRPCとProtocol Buffersという言葉が出てきました。これらはサーバー/クライアント間のAPI通信を実現するために役立つものです。しかし、Swaggerはツール、GraphQLはクエリ言語、gRPCとProtocol Buffersは設計指針（を実装したライブラリ）とデータフォーマットというように同格に扱えるものではないので、ちょっと混乱してしまいます。 そこで、この記事ではサーバー/クライアント間
REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク
REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク RESTful APIの仕様を基に、APIクライアント用SDK、APIクライアントのテスト用にAPIサーバのように振る舞ってくれるスタブサーバ、Webサーバのコンフィグレーション、ドキュメントなどを自動生成してくれる「OpenAPI Generator」がオープンソースとして公開されました。 RESTful API仕様の記述フォーマットは、2015年にマイクロソフトやGoogle、IBMらが立ち上げた「Open API Initiative」が提唱する「OpenAPI Specification」が事実上の業界標準となっており、OpenAPI GeneratorもこのOpenAPI Specificationを基に開
WEB Apiの話 (Restful) - Qiita
Twitter streaming api cybozudev api Restとは RESTはREpresentational State Transferの略。 RESTの原則に従って実装されているシステムのことを、RESTfulと呼ぶ。 RESTの世界では、ネットワーク上のコンテンツ(リソース)を一意なURLで表すのが基本。 各リソース（URL）に対してPOST、GET、PUT、DELETEでリクエストを送信する。 上のリクエストは、CRUD（Create、Read、Update、Delete）に紐付ける。 大体、レスポンスをXMLやjsonの形式で受け取る。 Restの設計 URL設計 リソースを名詞であらわす。例: /user/10 /song/5 video/7 POST は create, GET は read, PUT は update, DELETE は delete。H
REST APIの例外設計 - GeekFactory
REST APIを設計する場合に、エラーをどのステータスコードで返却するか議論になることがあります。例えば、以下のような場合が挙げられます。 キー指定のリクエストでDBにデータがない場合（例： GET /books/1 ） 一覧のリクエストでDBにデータがない場合（例： GET /books ） 必須項目がない、型が合わないといった場合（例： GET /books/find?count=bar ） ビジネスルールに違反する場合（例： POST /purchase ） 実行時エラー（例： NullPointerException ） クライアントが適切にエラーを処理できるように、レスポンスにエラー原因を入れることが一般的です。では、ステータスコードは何がいいのでしょうか。HTTPのステータスコードはRFCで定義されているし、RESTの考え方はWebや書籍にまとまっていますが、あくまでも考え方
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
Swaggerを使ってインタラクティブなWeb APIドキュメントをつくる - Qiita
この記事は、微妙に以下の記事の延長線上です。わかりにくければ、こちらから読んでいただいた方がいいかもしれません。 LittleBitsを使ったIoTをつくり、家の室温変化のグラフをインターネットから見る（前編） - Qiita 「インタラクティブなWeb APIドキュメント」とはどういうものか Swaggerというツールを使います。Web APIをYAMLで書いておいて、Swaggerでサーバを立てると、読むだけのドキュメントではなくて、以下のようにパラメータを指定して実際にHTTPリクエストを送ることができるWebページが生成されます。 以下が返ってきたレスポンスです。 以下は実物です。ご自由に動かしてみて下さい。 インタラクティブなWeb APIドキュメント まだちょっと分かりにくいという方のために、アノテーションからドキュメントを作れるswaggerの使い方 - gong023の日記
RESTful APIのエラー設計 - Qiita
RESTful APIのレスポンスデータ設計の最後でも述べたが、APIでエラーが発生した時のレスポンスデータも検討する必要がある。 エラー発生時のレスポンスデータの考え方 APIのレスポンスデータはほとんどの場合プログラムで処理されるため、エラーが発生した時も、 どんなエラーが発生したのか そのエラーはなぜ発生したのか そのエラーはどうすれば解決できるのか をプログラムが分かるようにしておく仕組みが必要。 エラー発生時のレスポンスデータ 1. HTTPステータスコードの設定 エラーが発生したら、レスポンスボディにエラー情報を設定するだけでなく、(RESTful APIのHTTPステータスコード設計でも書いた通り)適切なHTTPステータスコードを設定する必要がある(エラーが発生しているのに200を設定したりしないこと、200はリクエストが成功した時のみしか返してはいけない)。 2. レスポン
Android/iOSアプリ開発プロジェクトのRESTful APIのガイドラインを公開してみる - Qiita
これは何？ 今チームで使っているAPIガイドラインを公開してみます。 RESTful APIの設計のための資料をあさりつつ、アプリのクライアント向け（特にAndroid）やRuby (GrapeとRails)向けに調整したり決定したりした部分があり、その辺りのプラクティスが含まれています。 このガイドラインでは主にRESTful APIの一般的なプラクティスでは不足している内容について記述されています。 ※iOSはObjective-C製で、RestKitやMantleを使わずAFNetworking/NSURLSessionを使っていますが、AndroidはRetrofitを使っています。 （特にiOS用に）こうしたほうが良い！ということがあればコメントお待ちしております！ 副題：（チーム名）のAPIを支える技術 関連資料 書籍など Web API: The Good Parts 書籍、
現実世界のJSON Hyper-Schema / Real World JSON Hyper-Schema
Ruby Business User Conference 2015での発表資料です。
RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに
RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに 10年以上前、XMLの登場に続いてXMLベースのAPIを記述する標準フォーマット「WSDL」が提唱されました。 WSDLにはAPIの仕様がマシンリーダブルな形で記述されており、APIを呼び出すためのプロトコルやデータフォーマットをあらかじめ知ることができます。WSDLを利用することで、APIをコールするためのコードを自動生成することが可能でした。 しかしXMLベースのAPIは期待されたほど普及せず、現在ではよりシンプルなRESTful APIが事実上の標準となっています。 そしてRESTful APIのためのWSDLとも言うべき、RESTful APIのインターフェイスを記述するための標準フォーマットを推進する団体「Open AP
今さら聞けないWebAPIの実装方式RESTとSOAPの違い - Qiita
REST API RESTはREpresentational State Transferの略。 RESTの世界では、ネットワーク上のコンテンツ(リソース)を一意なURLで表すのが基本。 各リソース（URL）に対してGET,POST,PUT,DELETEでリクエストを送信しレスポンスをXMLやjsonなどで受け取る形式（レスポンスのフォーマット形式は指定されていない）。 RESTはURLがリソースに対応づけられるためURLは名詞的になることが多い。 SOAP API SOAPはSimpleObject Access Protocolの略。 リクエストおよびレスポンスともにXMLフォーマットのデータで行う形式。 SOAPのURLは操作と対応づけられるため、URLの命名が動詞的になることが多い。 参考： http://programming-10000.hatenadiary.jp/entry
RESTful#とは勉強会で(Railsでの)ルーティングの考えだし方の話をしました - moroのブログ
RESTful な設計って、ってマスタメンテ作るにはいいけどまともなサービス作れるの? という疑問に対して、結構やればアプリケーションできるので安心してください、という話をしました。 「独自研究」セクション以外はだいたいふつうに経験したことです。「独自研究」セクションはたぶん、今流行りのオーケストレイションレイヤをどうするかというところになるのかな、と。APIといいつつ、HTMLを返す話ばかりですが、これはAPIとHTMLをあえて区別せずそれは単にリプレゼンテーションが違うだけです、という意図でした。 転職してから初の社外発表が前職オフィスでやるというのが面白かったです。永和メンバーも結構たくさん会えてよかった。来てくださった方、開催をアレンジしてくださった方、ありがとうございました。
AWS LambdaをREST API Serverっぽく使ってみる - Qiita
はじめに AWS SummitのLambda関連のSessionに触発されてLambdaを色々触っていますが、Lambdaを既存のREST APIのServerの置き換えとして使えないか、という検討をしたメモをチラシの裏しておきます。 AWS Summitの資料はこちらにあります。Lambda関連のSession資料は以下2つ。 DEV-06 (Service）:Run Code in The Cloud : AWS Lambda 概要 DEV-08 (Mobile）:モバイル開発における AWS Lambda 活用法 追記 AmazonがAPI GatewayというServiceを発表しました。これを使えば、従来のREST API→API Gateway→Lambdaとつなげる事で、EC2無しでServer環境を作る事が可能になります。つまり、この記事に有る様なREST APIを無理矢理
[Android] OkHTTP + Retrofit + RxAndroid で REST クライアントを実装する | DevelopersIO
REST 処理を扱いやすく実装する Android の REST クライアントのネットワーク処理と非同期処理について、最近流行っている OkHTTP と Retrofit と RxAndroid の組み合わせを使ってみました。これらはそれぞれ次のような機能を提供するライブラリです。 RxJava の Android 版 リアクティブプログラミングを Android で実装するためのライブラリ イベントベースで遅延実行や非同期コールバックなどを実装可能 なお、Retrofit が OkHTTP と RxAndroid の架け橋になってくれるため、組み合わせてシンプルに記述可能になります。 導入 まずはこれら3つのライブラリを Android プロジェクトに導入しましょう。 dependencies { compile 'com.squareup.okhttp:okhttp:2.4.0' co
![[Android] OkHTTP + Retrofit + RxAndroid で REST クライアントを実装する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6f1fde3cff7767965729d2d96d3e31da5b8a643d/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_developers.io_1200x630.jpeg)
RESTful Web API 開発をささえる Garage - クックパッド開発者ブログ
技術部の小野(@taiki45)です。この記事では簡単なアプリケーション(ブログシステム)の実装を通して、クックパッドで作成・使用しているライブラリのGarage の紹介と Garage を使った RESTful Web API の開発をご紹介したいと思います。 Garage は RESTful Web API を開発するための、 Rails gemified plugins です。Rails プログラマは Garage を使って Rails を拡張することで素早く Web API を開発することができます。Garage は新しくアプリケーションを開発する場合にも、既存の Rails アプリケーションに組み込んで Web API を実装する場合でも使用できます。Garage はリソースのシリアライズやアクセスコントロールなど Web API の実装に必要な機能をカバーしています。 Ruby
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REST API設計者のための有名APIのURL例 - Qiita
https://qiita.com/magaya0403/items/0419d84d8df7784ac465
RESTfulとは
IBM Developer
