InfoQ: CRUDはRESTにとって良くないのか？Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
geo+webの人は皆「RESTful Web サービス」を買うべき - Relevant, Timely, and Accurate
d:id:hfu:20090316 に対するはてなブックマークで、yohei さんにコメントをいただきました。 任意矩形をquery paramsで取得するのはRESTfulに設計できます(RWS第5章)。サーバ内部の処理とインターフェース設計はまずは別に考えるべきと思います。 http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/hfu/20090316/1237148944 実は、RWS こと「RESTful Web サービス」、昨日入手したところでした。セレンディピティ*1、ですね。早速開いてみています。 RESTful な任意矩形指定 RWSこと「RESTful WEb サービス」5章 p.124 に、次のように書かれています。 http://maps.example.com/geologic/Earth/43.9,-103.46 この
ぶいてく: 【EC開発体験記 -リソース志向-】 APIをやめデータ構造に着目する
あらかじめ断っておくが、ここで説明するリソース志向は、私自身の開発の経験から必然的にたどり着いた解であって、一般的に説明されているROAとは多くの部分で異なる。ここでは、正確なROAの説明をするつもりはないし、本当のROAとは？などと、不毛な議論もやりたくない。ROAもしくはリソース志向という言葉を便宜上使わせていただいているが、それは、自分の解に一番近いと思われるからである。したがって、私の説明をそのまま世間で使うと痛い思いをするかもしれないので気をつけていただきたい。 まず、リソース（以下Resource）の定義から説明したい。Resourceとは、分析クラスから導き出されるEntityを具現化したものである。噛み砕いていうと、モデリングにより定義された自己完結したデータの集合という感じだ。前記事で、分析クラスのBoundary、Control、EntityをStrutsのMVCモデル
flowr ～ WEB間アプリケーションフレームワーク ～
flowrとは？ ブログや Wiki を使うときに、「使い勝手はこちらのツールが気に入っているんだけど、機能が足りないんだよなあ」とか「ブログサービスにこの機能を追加したいんだけど、勝手にそんなこと出来ないし……」などと思ったことはありませんか？ 他の人が作った Web アプリケーションやサービスの連携や拡張を行ったものの、相手がバージョンアップして仕様が変わってしまったために、作り直さなくてはならなくなったという経験はありませんか？ flowr (フラワー) はそれらの問題を解決しうる方法の一つとして構想している、「外付け可能な Web 間アプリケーションフレームワーク」です。 flowr の仕組み flowr が対象とするのは、パーマネントリンクを持つ Web アプリケーションです。一般的なブログや Wiki、Amazon のような製品情報ページの URL が一定のルールで固定化できる
Restlet - Lightweight REST framework for Java
What is an API (application programming interface)? Definition and examples A lot of people who work in technology have an intuitive understanding of what an API (application programming interface) is — but if you asked them to define it, they might have trouble putting an explanation into words. In simple terms, an API is both a piece of software running on a networked server and a component of p
CRISPY -
Overview CRISPY = Communication per Remote Invocation for different kinds of Services via ProxYs. The intention for this project is a very simple API to call different kinds of services (provider/technology). Crispy's aims is to provide a single point of entry for remote invocation for a wide number of transports: eg. RMI, EJB, JAX-RPC or XML-RPC. It works by using properties to configure a servic
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
