Google Cloud 公式ブログ404。 エラーが発生しました。リクエストされた URL /blog/ja/products/api-management/understanding-grpc-openapi-and-rest-and-when-to-use-them はこのサーバーで見つかりませんでした。お知らせできる情報は以上です。
REST APIの設計で消耗している感じたときのgRPC入門 - Qiita
REST APIによる設計 最近のシステムは様々なデバイスやスケーラビリティを重視するため、各システムを分割し軽量なAPIで連携するマイクロサービス的なアーキテクチャスタイルが増えてきています。 そして、そのAPI連携で広く採用されているのが、REST APIです。 しかし、こうした設計を行っていくには、適切に考慮、選択しなければならないことも多くあります。 URL、パラメータ、エラーなどの設計 各言語ごとのライブラリや、サーバ、クライアントの選定、設計 認証、認可 ドキュメント管理 ユニットテスト、インテグレーションテスト、モック、Consumer-Driven Contracts 開発用ツール 絶対的スタンダードがない状況下で、こういった問題はシステムやメンバーが増えるにつれ複雑化していき、設計や管理、その仕組み作りに時間を取られ、本来の目的となるべき機能開発の時間を失っていくことにな
なぜポスト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、
Moving existing API from REST to GraphQL
In 2016 I saw talks about GraphQL at almost every conference related to web development. A lot of posts and articles are issued about it. But all these things are mostly about basics of GraphQL or new features and looked superficially. So I’d like to tell about my personal experience of adopting a real big system to GraphQL. What’s wrong with RESTREST doesn’t separate concerns of transport, securi
[JA] API Development in 2017 / Takafumi ONAKA @onk
RubyKaigi 2017 http://rubykaigi.org/2017/presentations/onk.html Summarize "How to develop API server efficiently." This talk will talk while looking back on the history like Why REST (RESTful API) was born? The world has became to need Native client / Web front-end API documentation tool are widely used API Blueprint, Swagger, RAML, JSON Hyper-Schema Schema driven development API Query Language
![[JA] API Development in 2017 / Takafumi ONAKA @onk](https://cdn-ak-scissors.b.st-hatena.com/image/square/527d381b24e7653b9577cab21b0bde571ff9205a/height=288;version=1;width=512/https%3A%2F%2Fi.ytimg.com%2Fvi%2Fa28jJ62ZfZM%2Fhqdefault.jpg)
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
The last REST client you will ever need
Client-server architecture Different set of concerns Client cares about processing or rendering Server cares about storing and making information available efficiently Keeping concerns separate allow client and server to evolve independently Stateless Messages always contain all data needed to process the request Including authentication information if required That doesn't mean you can't use cook
Mobile API Design - Thinking Beyond REST — Stereoplex
This article explores the problems of optimising REST APIs for mobile device performance, and suggests a way of allowing clients to request alternate representations. Nate Aune and Anna Callahan gave a great talk at this year's EuroDjangoCon about a service that they'd built in 24 hours, valentun.es. Along with a great story, the meat of the talk was about the concessions you have to make with a m
Rest 勝利宣言
[OCPJ PoCWG Engineering Workshop] Zabbixを用いたOCPベアメタル監視環境の自動構築cloudconductor
RESTウェブサービスとWOAについて知っていなければならない12の事 - よねのはてな
先週11日に見た記事ですが、WOAという言葉に馴染みが無いせいか英語力の無さなのかイマイチぴんとこない。 12日に聞こうと思ってたんだけど。 12 Things You Should Know About REST Web Services and WOA 1.REST posits an interconnected information ecosystem, not an isolated set of point Web services. 1.RESTはWebサービスの相互接続に使うべきものであって、単独のWebサービスに使うものではない。 2.A focus on Design for Consumption instead of Design for Integration. 2.RESTは統合のためのデザインではなく、リソースを表現するデザインに注目すべき。 3.REST
REST 参考文献等 - RESTful読書会
REST Architecture Style † Roy Thomas Fielding: A little REST ard Relaxation, ApacheCon2008(?), 2008. http://roy.gbiv.com/talks/200804_REST_ApacheCon.pdf Roy T. Fielding and Richard N. Taylor: Principled design of the modern Web architecture, ACM Transactions on Internet Technology (TOIT), Vo.2, No.2, pp. 115-150, May 2002. http://doi.acm.org/10.1145/514183.514185 ↑ Service Model / Theory † Hul Ma,
MOONGIFT: » RESTfulなWeb APIを使う開発者は必須「eXeve」:オープンソースを毎日紹介
Memotuneでは現在、Web APIを開発している。GDataに準拠しているので、Web APIの形式はRESTfulだ。ただ、RESTfulは最近の流行とは言え、問題がない訳ではない。 最大の問題はテスト環境だ。PUTやDELETEといったHTTPメソッドを手軽に試せない。IEやFirefoxは対応しているようだが、おそらく手軽には試せないだろう。 そこで専用のクライアントを使うのが良い。RESTfulに限らず、XMLを経由したMashup開発者は必須ではないだろうか。 今回紹介するフリーウェアはeXeve、RESTfulなWebアプリケーション開発ユーティリティだ。 eXeveを使うとWeb APIとやり取りするXMLが簡単に作成できる。構造チェックやDTDによる検証ができればよけいなミスも減るはずだ。 また、PUTやDELETEといったHTTPメソッドを使ってデータを授受する事も
考えさせられる - yojikのlog
RubyKaigi2006 RESTのPOST,GET,PUT,DELETEとDB(というかリソース)のCRUDの類似。Webアプリケーションにおける殆どの操作は、リソースのCRUDに対応させることができる。*1 実際のアプリのレベルに落として考えると、例えばユーザをグループに追加する際に、ユーザコントローラに対して「グループに加入させよ」メッセージを送る*2のではなく、メンバシップコントローラに、ユーザ-グループ間のメンバシップをCREATE(REST的にはPOSTで依頼)してもらう事になる。*3。 上記を徹底すればWeb(アプリ|サービス)が、外部からDBのように扱えるようになる。多分、この話がActiveResourceに繋がる。(のだと思う) なんか学ぶべき点が多そうです。 あと個人的には、DBのように扱うためには、ユーザ(や他のアプリ)との対話の中で、適切な単位でCRUDを纏め上
PHPからMySQLをRESTで操作するPHP REST SQL:phpspot開発日誌
PHP REST SQL: A HTTP REST interface to MySQL written in PHP PHP REST SQL was built and tested using Apache 2.0.45, PHP 4.3.4, and MySQL 3.23, although it should work with any version of PHP4 and MySQL and any HTTP server that will pass requests of all HTTP method types to PHP. PHPを使ってRESTによるMySQL操作を可能にするPHP REST SQL。 サイト上の例を見るところによると具体的に、次のようなRESTインタフェースにてMySQL操作が可能になる模様。 ●データの取得 SELECT * FROM tab
http://www.feedsphere.com/2006/05/rest_vs_webservicerpc.html
For full functionality of this site it is necessary to enable JavaScript. Here are the instructions how to enable JavaScript in your web browser.
naoyaのはてなダイアリー - REST と GET
RESTful なアプリケーションでは、対象とするリソースに副作用を及ぼすときは POST なり PUT を使うのがベストプラクティス。(ベストプラクティスという言葉を使ってみたかった!) この考え方はウェブアプリケーションを作るときに、GET にするか POST にするかに明確な指針を与えてくれてすっきりします。 で、ふと思ったんだけど、表面的には GET でよさそうだけども実は中でリソースに副作用が及んでいるような代物はどうしたらいいんだろうなということ。例えば検索エンジンなんかで、クリックに合わせて後ろでクリック回数を数えてたり統計とってたりするものがあると思うんだけど、そういう類。 ウェブサイトの検索エンジンとかだとクリック対象の URI が差すリソースが外部サイトでちょっとイメージしづらいので、例えば search.cpan.org など。モジュールの検索結果からのクリック回数を
RESTが難しいってことについて - Ogawa::Memoranda
Posted by: Hirotaka Ogawa @ April 26, 2006 06:01 PM | 暇を見つけてGoogle Data APIs Protocolをしげしげと読んでみていた。よくできているね。 Google Data APIs Protocol ところで話はかわって、識者の人々が「RESTは難しい」「RESTを説明するのは難しい」と繰り返し発言している。事情に詳しくない(しかし興味は持っている)市井の人々に「そうなんだー、難しいんだー」という気分が蔓延するのは、REST推進派の人々にはネガティブに作用するはずで、なんでそんな発言をするのだろうと思う。私自身は門外漢なこともあって「難しい」理由がいまいちよく分からない。なんも難しくないと思えるけれど。 で、冒頭の話に戻るわけで、もしそんなに「RESTが難しい」のなら、もう「Google Data」互換APIを実現するフ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Best Gambling Sites in Canada - Top Lists By Lucky Marmot
InfoQ: RESTの良い点、悪い点、ひどい点
