Zalando RESTful API と イベントスキーマのガイドライン
Zalandoのソフトウェアアーキテクチャは、疎結合なマイクロサービスを中心としており、 それらはJSONペイロードをもつRESTful API群によって、機能が提供されています。 小さなエンジニアのチームは、自分たちでAWSアカウントにこれらのマイクロサービスを デプロイしたり運用したりしています。 私たちのAPIは、その多くが私たちのシステムが何をするのかを完全に表現しており、 それゆえに貴重なビジネス資産となっています。 Zalandoがとあるオンラインショップから価値あるファッションプラットフォームへと変貌を とげるために、私たちは新しいオープンプラットフォーム戦略の展開をはじめました。 なので、高品質で長持ちするAPIの設計は、私たちにとってよりクリティカルなものになってきているのです。 私たちのビジネスパートナーがサードパーティのアプリケーションから使える公開APIをたくさん
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
RESTful Web アプリの設計レビューの話
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
Railsの誤解：CRUDはRESTじゃない！ - 杉風呂2.0 - A Lifelog -
以下はNick Sutterer氏が2010年10月28日に自身のブログに投稿した、"Rails Misapprehensions: CRUD is not REST! "の翻訳です。本人の許可を得て掲載します。 Rails Misapprehensions: CRUD is not REST! http://nicksda.apotomo.de/2010/10/rails-misapprehensions-crud-is-not-rest/ RailsとRESTについて調べている間、二つのことがよくわかった。 RailsでRESTがどうなっているのか、他と比べて、明解で、基礎的で、「印刷された」解説を見つけにくい。数千のスクリーンキャストを見てきたが、この素晴らしいガイドが一つあるだけだった。 みんなCRUDとRESTを混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると
RESTに対する７つの誤解
海外に行くと、既に REST対SOAPの決着は付いている[1]（エンタープライズでもコンシューマでも）ように見えるのだが、日本国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。（殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション：RESTの詳細でより詳細に書かれている。） 誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか？ どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。 もちろん間違いである。 ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTT
次世代Webフレームワークの設計思想～RESTful Webサービス - プログラマの思索
「RESTful Webサービス」本を買ってみた。 まだ読んでないけれど、この本を買った動機を振り返ってみる。 【1】Webフレームワークの歴史とその限界 Webアプリは最初はオモチャみたいなものだった。 普通は、掲示板のようなアプリをPerlでCGIを書いて作っていただろう。 そして次第に、ViewからControllerを分離する設計をするようになった。 Javaの場合、JSP＋Servletという仕組み。 だが、システムが巨大化していくうちに、Webフレームワークが必要とされるようになってきた。 そのWebフレームワークの基本思想として、MVC2モデルが叫ばれるようになった。 MVC2モデルは、GUIアプリのMVCモデルのWeb版といっていい。 この思想によって、大概のWebフレームワークは、MVC2モデルを標榜するようになった。 そして、Javaはこの思想を突き詰めて、Model部
SOAPからRESTへ - プログラマの思索
InfoQの記事「InfoQ: SOAP から REST へ - その方法と意義」が良かったのでメモ。 【元ネタ】 InfoQ: SOAP から REST へ - その方法と意義 次世代Webフレームワークの設計思想～RESTful Webサービス: プログラマの思索 REST思想とHTTPメソッドの関係: プログラマの思索 Ruby on Rails + Curl リッチクライアントCRUDアプリを作成する（1/5）：CodeZine RedmineのRESTful APIを使う: プログラマの思索 SOA(サービス指向アーキテクチャ)はバズワードだ。 SOAこそが今後の設計の将来だ、と言われた時期があったけれど、結局使いづらかったのではないか。 SOAを支えるエンタープライズ系技術としてSOAP、WSDLなどが声高に叫ばれたが、結局廃れてしまったか、傍流の技術になってしまったように思う
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Charming Python: Functional programming in Python, Part 3
SOAP から REST へ - その方法と意義