タグ

RESTに関するgiassのブックマーク (6)

  • 【徹底解説】REST VS GraphQL

    注意:今回の記事で載せているコードは読者に具体的なコードのイメージを持たせる目的で書いている。それ故に、実際にブラウザ上で実行しても動作しない点には注意してほしい。より専門的ににGraphQLとRESTの違いを学びたいならLogRocketの記事とApolloの記事を参考に。 はじめに 今回の記事では、Web APIの開発に重宝されるRESTとGraphQLの違いを解説する。 対象とする読者 これからREST、またはGraphQLを実務で積極的に活用したいひと 両者の違いがわからないひと 個人開発等でWeb APIをつくるひと タイトルを見てなんとなく気になったひと APIとは RESTとGraphQLの議論に入る前に、まずはAPIについて説明する必要がある。 Wikipediaによると、API(Application Programming Interface)は以下のように定義されてい

    【徹底解説】REST VS GraphQL
    giass
    giass 2023/07/24
  • REST API開発に特化したWebフレームワークがもたらす生産性の向上 | IIJ Engineers Blog

    皆さんはREST APIの開発にどのようなフレームワークをお使いでしょうか? これまで、個人的には Flask 等の軽量なWebフレームワークを使って開発することが多く、REST API開発に特化したWebフレームワーク(以下、APIフレームワークと呼ぶ)を使った経験はありませんでした。 しかし先日、業務で Django REST Framework に触れる機会があり、REST APIの実装に必要な機能の多くが提供されていて、圧倒的に少ないコーディング量で開発が完了することを実感できました。例えば、フィルタリング(URLクエリストリングで検索条件等を指定し、取得する値を絞り込む)機能は、一から実装するとなると文字列をパースして、バリデーションして、クエリに渡して……、と結構面倒ですが、Django REST Frameworkではビルトイン機能として提供されているので、最小限のコードで実

    REST API開発に特化したWebフレームワークがもたらす生産性の向上 | IIJ Engineers Blog
    giass
    giass 2020/03/08
  • GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白

    DISCLAIMER: これは当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう

    GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
    giass
    giass 2018/07/13
  • REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク

    REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク RESTful APIの仕様を基に、APIクライアント用SDK、APIクライアントのテスト用にAPIサーバのように振る舞ってくれるスタブサーバ、Webサーバのコンフィグレーション、ドキュメントなどを自動生成してくれる「OpenAPI Generator」がオープンソースとして公開されました。 RESTful API仕様の記述フォーマットは、2015年にマイクロソフトやGoogle、IBMらが立ち上げた「Open API Initiative」が提唱する「OpenAPI Specification」が事実上の業界標準となっており、OpenAPI GeneratorもこのOpenAPI Specificationを基に開

    REST API仕様からAPIクライアントやスタブサーバを自動生成する「OpenAPI Generator」オープンソースで公開。Swagger Codegenからのフォーク
    giass
    giass 2018/05/15
  • 時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了

    SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I(Web Services Interoperability Organization)が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました(参考:WS-I Completes Web Services Interoperability Standards Work(pdf))。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST(Representational State Transfer)と呼ばれるアーキテクチ

    時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了
  • Jersey、AJAX、JSONを使ってRESTに挑戦しよう

    はじめに REST(Representational State Transfer)は、HTTPを介した包括的な方法でデータを扱うことを可能とする、強力で軽量なアーキテクチャです。しかし、強力であるとはいえ、独自のコードにRESTを取り入れるのは少々手間がかかるため、何らかの支援が必要になります。Javaでのコーディングの場合は、Jerseyが助けになります。Jerseyは、JavaコードをREST対応にするために必要な作業を簡素化するオープンソースプロジェクトです。 この記事では、RESTを簡単に紹介し、Jerseyの背景にある基的な動作概念を説明します。次に、Jerseyを使用して、実際のJavaコードをRESTfulにする方法を示します。最後に、ブラウザベースのJavaScript、AJAX、およびJSONを使用して、作成したRESTfulコードにアクセスする方法を示します。関連ト

    Jersey、AJAX、JSONを使ってRESTに挑戦しよう
    giass
    giass 2009/12/10
    トランプ画像
  • 1