The Hypertext Application Language
HAL - Hypertext Application Language A lean hypermedia type Author: Mike Kelly <[email protected]> Created: 2011-06-13 Updated: 2013-09-18 (Updated) Summary HAL is a simple format that gives a consistent and easy way to hyperlink between resources in your API. Adopting HAL will make your API explorable, and its documentation easily discoverable from within the API itself. In short, it will make yo
- The RESTful cookbook
Welcome to the REST CookBook REST is hot! And REST is finally rediscovered by API programmers all over the world. But REST isn't always as easy as it seems on first look. Dealing with HATEOAS, Code on demand and uniform interfaces can be really tricky and many people will fall back to not-so-restful approaches when things are starting to become more difficult. But it doesn't need to be. Once you g
The Netflix Dynamic Scripting Platform
by Sangeeta Narayanan Over the past couple of years, we have optimized the Netflix API with a view towards improving performance and increasing agility. In doing so, the API has evolved from a provider of RESTful web services to a platform that distributes development and deployment of new functionality across various teams within Netflix. At the core of the redesign is a Dynamic Scripting Platfor
10 Best Practices for Better RESTful API | Thinking Mobile
Do not use verbs: /getAllCars /createNewCar /deleteAllRedCars 2. GET method and query parameters should not alter the state Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET for state changes: GET /users/711?activate or GET /users/711/activate 3. Use plural nouns Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all r
HerokuのつくってるAPI関係の便利なやつ - ✘╹◡╹✘
JSON Schema for the Heroku Platform APIでも紹介されているように、HerokuのAPIはJSON schemaで記述されたAPIの仕様を返すようなAPIがあって(ややこしい)、Auto-generating a Go API client for Herokuのようにこれを利用してAPIクライアントを自動生成するようなこともやってる(単なるアート作品じゃなくて実際に運用されているので偉い)。Herokuが出してるAPI関連作品の1つにcommittieというのがあって、JSON schemaを利用してAPIの仕様を定義して、それをRack middlewareで利用しようというもの。前に試しに似たようなのつくってたので良いのが出てきて良かった。 Committieは大きく分けて3種類の機能を提供していて、1つは本番環境で普通に使うやつで、リクエストをv
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
mit-license.org
Open Source InitiativeのMITライセンスのページのURLを使ってMITライセンスと明示している人は結構多いと思います。ライセンス全文コピペするの面倒ですしね……。ただその場合は権利者の名前等を予め書き、ライセンス条項については以下のURLを参照……などと注意書きも含めた方が無難です。そういうのを「忘れるし！ 面倒だし！」と思ったRemy Sharpがmit-license.orgというウェブサービスを作ってくれました。 登録するとユーザー名をサブドメインとしたURLが確保されます。例えば僕の場合はhail2u.mit-license.orgです。このページを見るとわかるように権利者の名前と発行年、オプションとしてWebサイトのURLにリンクを張れたりもします。 curlでJSONを送りつけるという方法でも登録できるみたいですが、JSONファイルの登録とバッティングした
Microsoft Learn: Build skills that open doors in your career
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
RESTful Meetup vol.3 を開催しました #RWABookja - ぶろぐ。@はてな
4/12(土)の夜に『RESTful Meetup vol.3』を開催しました。 RESTful Meetup vol.3 - Sendagaya.rb | Doorkeeper 昨年の記事の通り『RESTful Web APIs』の読書会を月2回ペースで開催してきましたが、その後、著者のMike Amundsen(@mamund)さんから、ワークショップのために東京へ行くという知らせがあったので、これはイベントをやるしかない！ということで企画しました。 vol.3ということで、実は過去2回開催しています。そのときは『RailsにおけるRESTfulなURL設計勉強会』というタイトルで、かなりターゲットを絞っていたのですが、今回は「REST」「Web API」というかなり広いテーマにしました。このことでRuby/Railsに限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ
ハイパーメディアAPIをめぐるREST主義者的危機
ソフトウェア開発者のEvan Cordell氏は数週間前のAPI-Craftメールリストで，ハイパーメディアのREST制約は一般的なWeb API要件とどのように違うのか，という議論の口火を切った。 "REST主義者的危機(RESTistential crisis)"と題した論議の中で氏は，長年の議論と実践によってRESTスタイル最大の秘密，ハイパーメディア制約が明確になり始めたことを指摘している。Webでも明らかなように，人間中心のインタラクションには完璧に対応しているが，その一方でプログラマブルなWeb API一般においては，有用性に対する懸念がWeb APIコミュニティの中で増しつつあるようなのだ。 RESTに関する説明，ドメイン特有のWeb APIに適用した場合のハイパーメディアの制限，といった話題から始まった今回の議論では，新たなアーキテクチャスタイルの必要性の検討や，RESTを
Reviewing RESTful Web Apps
This document summarizes Takuto Wada's presentation on reviewing RESTful web apps. It discusses best practices for designing RESTful resources and representations, including using nouns instead of verbs in URLs, making URLs reflect the meaning of resources, and ensuring resources are connected through hypermedia links and forms. It also covers appropriate use of HTTP methods, status codes, and con
BEAR.Sunday
BEAR.Sunday is a resource orientated framework with a REST centered architecture, implementing Dependency Injection and Aspect Orientated Programming' at its core. Learn more »
《REST思想》と《リソース指向》と《Webページ》に関する（主にRailsの）話 - Qiita
これはいわゆるWeb APIについて、ということかなと推測しました。RESTというのはAPIのプロトコルのことだと思われている傾向がありますが、そういうわけではありません。Web全体についてのもので、APIについてもWebアプリについても適用されるものです。 実はRESTでは「統一インターフェイス」の制約からメソッドについて規定されていますが、URLの形については特に規定されません（もちろんAddressabilityの面で重要であることは言うまでもありません）。なので実は/books,/books/1でなくてもいいのですが、これを規約(CoC)でズバッときれいに決めてしまったのがRailsのすごいところの1つです。 本の追加や削除を行う場合は、本情報をJSON形式でPOSTリクエストのボディとして送ります。application/x-www-form-urlencoded形式で送ることは
Ruby RoguesメンバとiOSエンジニアのAPI議論 - ワザノバ | wazanova
http://rubyrogues.com/147-rr-apis-that-dont-suck-with-michele-titolo/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 iOSエンジニアのMichele Titoloは、Objective-Cのディペンデンシーを管理するCocoaPodsのプロジェクトで知られてますが、モバイルエンジニアの立場からAPIを利用して開発するポイントについても、自らのブログでまとめています。 1) Follow Conventions はじめてのことにトライするときは先駆者の知恵に従うほうが、クオリティの高いものをつくれるので、conventionに従うのがよい。そのほうがデバッグもしやすい。自分でAPIのルールを定義する必要が生じた場合は、一貫性を維持し
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
Designing a REST API: Unix time vs ISO-8601
Designing a REST API: Unix time vs ISO-8601 Published on: February 22, 2013 In what format should a REST API return and accept timestamps? The two most popular ways are Unix time (or a slight variation thereof) or ISO-8601. Both have their strengths and weaknesses and both are equally popular as we shall see. A sample of 20 APIs yielded nearly a 50/50 split. Therefore, no matter if this holds any
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
interagent
GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API
なぜ html の form は PUT / DELETE をサポートしないのか？
