なぜポストREST APIが求められるのか？ REST APIがカバーできない2つの要因とその対策 - Morning Girl
なんだか珍しく、あおり気味のタイトルにしてしまいました。 最近読んだ以下の記事が大変おもしろかったので、今まで私の中で度々反芻していたものを文章としてまとめてみました。 gihyo.jp なぜ今GraphQLが騒がれているのか。ポストRESTが求められている理由、なぜポストRESTが求められなければいけないのか？ ポストRESTの登場によって私たちにとって何が嬉しくなるのか？ そのあたりを色々と触れていきたいと思います。 本文に入る前に ここでは、RESTと記載していものに、REST ful であることも含めています。RESTの推奨（規約ではない）に準拠して開発されたAPIをREST Fulと呼ぶのであって、そこにAPIとしての違いは無いためです。 どちらかと言えば、私の意識としてはパブリックなAPI、オープンデータ用のAPIであったり、KintoneやSANSAN、Salesforce、
Django REST Frameworkを使って爆速でAPIを実装する - Qiita
この記事は「Python その2」Advent Calendar 2015の14日目です。 何を書こうか迷ってましたが、今年学んだPython関係の技術で一番恩恵を預かったREST Frameworkについて書いてみようと思います。 はじめに APIを作るのは結構面倒 初めにAPIを作るということの難易度に触れておこうと思います。 実際に作った経験のある方も多いと思いますが、WebAPIはWebページと違ってロジックのみに集中して開発できるので、開発しやすいといえば開発しやすいです。デザインや利用環境気にしたり、HTMLやJavascriptような複数の言語を駆使する必要も全く無いです。レスポンスを正しく受け取って適切にレスポンスを返すだけ。 とはいうものの実際作ってみると面倒な事が多く出てきます。例えば入力された値が正しいのかどうかをチェックしたりだとか、複数の条件で結果をフィルタリング
WebAPIの設計から実装まで〜設計編〜 - Qiita
WebAPIを設計から実装までした時に考えたことや書いたコードをまとめていく。 今回は設計思想について 実装編書きました→WebAPIの設計から実装まで〜実装編〜 GitHubのレポジトリ→chat_app そもそもWebAPIとは WebAPIとは、 特定のURLに値とともにアクセスするとデータベースから必要なデータを取ってきてそれをクライアント（ユーザー側）にそのデータを送信する。 参考→エンジニア視点から見るWebサービスの全体像 WebAPIのデータフロー 下図のように設計した Client→Route・・・ClientからAPIにRequestを送る Route→Controller・・・RouteでURLを解析してControllerにDispatchする Controller→Service・・・Controllerでデータを整理してServiceに投げる Service→D
GoogleのWebAPI設計とWebAPI設計のベストプラクティスを比較してみる
RESTful な URL にしよう 元記事 GET /tickets - チケットのリストを取得する GET /tickets/12 - 指定したチケットの情報を取得する POST /tickets - 新しいチケットを作成する PUT /tickets/12 - チケット #12 を更新する PATCH /tickets/12 - チケット #12 を部分的に更新する DELETE /tickets/12 - チケット #12 を削除する Google GET /events - 予定のリストを取得する GET /events/12 - 指定した予定の情報を取得する POST /events - 新しい予定を作成する PUT /events/12 - 予定 #12 を更新する PATCH /events/12 - 予定 #12 を部分的に更新する DELETE /events/12 -
API design guide | Cloud APIs | Google Cloud
Send feedback API design guide Stay organized with collections Save and categorize content based on your preferences. Changelog Introduction This is a general design guide for networked APIs. It has been used inside Google since 2014 and is the guide that Google follows when designing Cloud APIs and other Google APIs. This design guide is shared here to inform outside developers and to make it eas
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
初めてWeb API設計をする前に読みたい記事・本・API実例と個人的にハマったこと - 仮想サーファーの日常
働いている会社で「サービス全体のサーバーサイドの処理をAPIに置きかえよう！」というプロジェクトにアサインされて、初めてAPIをゼロから設計する仕事をすることになって早1ヶ月。初めてだらけで何度も悩みながらAPI設計をし続けていますが、1ヶ月前に比べてだいぶいろんな記事や本にお世話になってきたので、個人的に参考になったなあと思うものたちをまとめておきます。 あと、API設計を進めていく上で個人的にハマったことも書いておきます。後世のAPI設計者が同じような疑問にぶつかった時にハマらないことを願います。（自分の記憶力が🐔レベルなので、メモの意味でもまとめておきます。） API設計する上で参考になった記事 まずは、初心者の段階で読んでおきたい記事たち。まずはAPI設計はどのように進めていくべきか、どのようなところでハマりやすいのかを知るために記事を読んで大枠を掴むと良いかと思います。 Web
REST APIとは？ - API設計のポイント
最近は様々なサービスでWebAPIが提供されています。普段の開発をする中でもシステム連携などでAPIを作る機会が出てくるのではないでしょうか。 WebAPIの中でもREST APIなんてものもよく聞くのかなぁと思います。REST APIの設計は色々と奥が深く、なかなかおもしろい技術です。 今回はそんなREST APIを設計する上でのポイントをご紹介していきます。この記事では実装よりも設計思想的な部分を書いています。次回以降にもう少し実装に近いレベル記事を書いきます！ REST APIとはRESTの原則に沿った形で設計されたAPIを指します。 じゃあ、RESTってなんぞや？となると思いますが、参考サイトにはこんなことが書かれています。 「セッションなどの状態管理を行わない（やり取りされる情報はそれ自体で完結して解釈することができる）」（Webシステムでは、HTTP自体にはセッション管理の機構
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
