API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
The Collaborative API Development Platform
New Release - Insomnia 8.0 is finally here with Scratch Pad, Real-Time Collaboration, Enterprise SSO, AI-Generated Testing Design, debug, and test APIs locally or in the cloudChoose Local, Cloud, or Git storage to build better APIs collaboratively with a dev-friendly UI, built-in automation, and an extensible plugin ecosystem. Get Started for Free
REST APIの例外設計 - GeekFactory
REST APIを設計する場合に、エラーをどのステータスコードで返却するか議論になることがあります。例えば、以下のような場合が挙げられます。 キー指定のリクエストでDBにデータがない場合（例： GET /books/1 ） 一覧のリクエストでDBにデータがない場合（例： GET /books ） 必須項目がない、型が合わないといった場合（例： GET /books/find?count=bar ） ビジネスルールに違反する場合（例： POST /purchase ） 実行時エラー（例： NullPointerException ） クライアントが適切にエラーを処理できるように、レスポンスにエラー原因を入れることが一般的です。では、ステータスコードは何がいいのでしょうか。HTTPのステータスコードはRFCで定義されているし、RESTの考え方はWebや書籍にまとまっていますが、あくまでも考え方
Retrofit
Introduction Retrofit turns your HTTP API into a Java interface. public interface GitHubService { @GET("users/{user}/repos") Call<List<Repo>> listRepos(@Path("user") String user); } The Retrofit class generates an implementation of the GitHubService interface. Retrofit retrofit = new Retrofit.Builder() .baseUrl("https://api.github.com/") .build(); GitHubService service = retrofit.create(GitHubServ
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
企業システムプログラマとWeb系プログラマの差 - L'eclat des jours(2009-12-12)
_ HATEOAS はて、こんな言葉知らないぞと思ったけど検索してみると結構見ていた。 Hypermedia As The Engine Of Application State _ 企業システムプログラマとWeb系プログラマの差 Web系という言い方はどうよというのはあるだろうけど、そう分類したとしてだ、次のような対比ができるかも知れないかも知れないかも知れない程度には感じること。 ・REST何それ？ 対 当然REST ・REST難しそう 対 RESTだから簡単 ・で、開発言語は？ 対 で、URIは？ ・で、RESTのツールは？ 対 で、JSONは返るの？ それともXML？ ・で、REST用プラグインは？ 対 で、作っちまったからgitで公開な でも待て、JAX-RSがあるぜ、と。
RESTとトランザクション？
原文(投稿日：2009/6/15)へのリンク RESTとその他のアプローチ(特にWebサービス)の利点の比較、もしくはもっと単純にRESTをWebベースのインテグレーションで利用する利点に関して、長い間、議論されてきた。議論は続いているが、他の領域では当然と思われていて、REST、特にREST/HTTPに欠けている機能があるのかどうかという点を、一部の人は議論の対象にしようとしている。それらのうちの一つに、分散トランザクションがある。Bill Burke氏がRESTeasyに実装した内容を示し、コメントを求めたことから始まった、REST-discussion メーリングリストでのやりとりがあった。 素晴らしくきれいなAPIです。私はシステムによって公開されるURIの数を減らし、システム全体の柔軟性を高めるために、AtomのLinkで、発行されるURI schemeのいくつかを置き換えられな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ktor REST Apis — Part 1 (Project Set up)
GoでAPIサーバをはやくつくる
Home | Dropwizard
IBM Developer
IBM Developer
ITとクラウド管理におけるRESTの役割 - クラウドAPIの比較
IBM Developer
IBM Developer