IntelliJ IDEA 2017.3 EAPからのeditor-based REST clientを試す - しおしお
IntelliJ IDEA 2017.3(今はEAP)から追加されたeditor-based REST clientを試してみたよ。 詳しくは、What’s New in IntelliJ IDEA 2017.3 EAP? | IntelliJ IDEA BlogのToolsに書かれてるよ。 試すために作ったサーバ側のコード GETとPOSTを確認するためだけの簡単な実装で・・・ @RestController @RequestMapping("/api") class Api { data class Data(val value: String) @GetMapping fun get(@RequestHeader("X-Hoge") hoge: String): Data = Data("X-Hogeは $hoge でした") @PostMapping fun post(@Reque
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
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なAPIがつらくなってきた話 - ○△□ - yudppp techblog
この記事はCyberAgent エンジニア Advent Calendar 2015の13日目の記事です。 昨日は同期のmatsuokahさんのブログでした。明日はhuydxさんのブログです。 はじめに 新卒3年目の鈴木(@yudppp)です。 入社してからJavaやったりNode.jsやったりフロントかじったりしていました。 ここ1年はGolangでサーバーサイドのエンジニアをしていました。最近はNetflixを見てゆったりした休日を過ごしています。 会社関連のちゃんとしたブログを書くのはじめてなので柔らかめなマサカリください。 2年以上RESTを意識してAPIを作りつづけていました。 RESTful APIについては同期の鈴木が紹介していたのでこちらを参考にしてください。 また悩んだときはWEB+DB PRESS Vol.82の特集を読み返したりしてました。 ただ開発を進めていくうちに
REST サービスから返ってくる XML の読み方 - SharePoint Developer
ここでは、先ほどのリストの一覧を取得する URL を呼び出した時に返ってくる XML を例に、 XML の読み方を説明します。 REST サービスを呼び出すと返ってくる XML は下図のようなものになっています。 この XML は ATOM という形式 (XML の書き方) で記述されています。 XML を上から見ていくと、 途中から entry というタグが出てきます。 この entry タグの中身が 1 行分のデータとなっており、先ほどの URL を呼び出すとリスト、ライブラリの分だけ entry タグが含まれる形で XML が返ってきます。 entry タグの中身を見ると、上図のように link タグがずらっと並び、その後に下図のような m:property タグが続きます。 m:property タグの中身(d:Title タグなど)が実際の値が含まれるタグの一覧で、タグの名前から
REST サービスでサイト、リスト、アイテムを取得する - SharePoint Developer
はじめに今回は REST サービスを使ってサイト、リスト、アイテムのプロパティを取得する方法を説明します。 ここで説明する内容はブラウザと SharePoint があればすぐに試せるので、実際に動かしながら読んでみてください。 なお、REST サービスから返ってくる XML の読み方は前回説明していますので、そちらを参照してください。 サイトのプロパティを取得するまずは REST を使って任意のサイトのプロパティを取得する方法です。
今さら聞けないWebAPIの実装方式RESTとSOAPの違い - Qiita
REST API RESTはREpresentational State Transferの略。 RESTの世界では、ネットワーク上のコンテンツ(リソース)を一意なURLで表すのが基本。 各リソース（URL）に対してGET,POST,PUT,DELETEでリクエストを送信しレスポンスをXMLやjsonなどで受け取る形式（レスポンスのフォーマット形式は指定されていない）。 RESTはURLがリソースに対応づけられるためURLは名詞的になることが多い。 SOAP API SOAPはSimpleObject Access Protocolの略。 リクエストおよびレスポンスともにXMLフォーマットのデータで行う形式。 SOAPのURLは操作と対応づけられるため、URLの命名が動詞的になることが多い。 参考： http://programming-10000.hatenadiary.jp/entry
HATEOASって何だ? - uehaj's blog
Grails 2.3のRest機能のドキュメントを読んでいたら、拡張の一つとして「8.1.7 Hypermedia as the Engine of Application State」というのが書いてあって、調べると面白かったので、この資料(REST: From GET to HATEOAS)を読んだだけでの、私の理解する限りのメモを記しておきます。 一言でいうと、HATEOASとは、Restfulパターンを拡張するアーキテクチャパターンで、Restful原則に対する追加的な制約。どういうものかというと、HTMLアプリの画面遷移を抽象化した、状態遷移を表現するRestful API(=Restful WebアプリのWebインターフェース)を設計するための具体的な方法論になってる。 もちろんGrailsに特化したものではなく、Restと同じレベルのWebアプリケーション一般概念でありRes
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
wiki.fitbit.com - Google Single Sign On: Sign into corp