আপনার ইউআরএল কাঠামো আরও কম বা অবাধে পরিবর্তন করার ক্ষমতা ছাড়াও হেটিওএএস আবিষ্কারযোগ্যতা এবং ডিকোপলিংয়ের জন্য কী প্রস্তাব দেয়?

Question

ইদানীং আমি হাইপারমিডিয়া সম্পর্কে ইঞ্জিন অফ অ্যাপ্লিকেশন স্টেট (হ্যাটোওএএস) হিসাবে পড়ছি, এটি একটি প্রতিবন্ধকতা যা একটি ওয়েব এপিআইকে "সত্যিকারের রেস্টস্টুল" হিসাবে দাবি করে is এটি বর্তমান অবস্থা থেকে আপনি যে সম্ভাব্য রূপান্তর করতে পারেন তার প্রতিটি প্রতিক্রিয়াটির সাথে মূলত লিঙ্কগুলি অন্তর্ভুক্ত করে।

আমার বোঝার উপর ভিত্তি করে হেটোয়াস কী তা বর্ণনা করার জন্য - এবং আমি যদি কিছু মিস করি তবে দয়া করে আমাকে সংশোধন করুন।

/
    GET: {
        "_links": {
            "child": [
                { "href": "http://myapi.com/articles", "title": "articles" }
            ]
        }
    }

/articles?contains=HATEOAS
    GET: {
        "_items": [
            { "uri": "http://myapi.com/articles/0", "title": "Why Should I Care About HATEOAS?" },
            { "uri": "http://myapi.com/articles/1", "title": "HATEOAS: Problem or Solution?" }
        ],
        "_links": {
            "self": { "href": "http://myapi.com/articles", "title": "articles" },
            "parent": { "href": "http://myapi.com/", "title": "home" }
        }
    }

    POST: {
        "title": "A New Article",
        "body": "Article body",
        "tags": [ "tag1", "tag2" ]
    }

/articles/0
    GET: {
        "title": "Why Should I Care About HATEOAS?",
        "body": "Blah blah blah"
        "tags": [ "REST", "HATEOAS" ],
        "_links": {
            "self": { "href": "http://myapi.com/articles/0", "title": "article" },
            "parent": { "href": "http://myapi.com/articles", "title": "articles" }
        }
    }

HATEOAS দুটি প্রধান সুবিধা প্রদান করার জন্য দাবি করা হয়েছে:

1. মূল পরিষেবাটি ইউআরআই মূল রূপটি আবিষ্কার করার যোগ্য, ডকুমেন্টেশনের আর প্রয়োজন নেই।

2. ক্লায়েন্টটি সার্ভার থেকে ডিউলড হয়েছে যা এখন ইউআরআই কাঠামোকে অবাধে পরিবর্তন করতে পারে। এটি API সংস্করণকরণের প্রয়োজনীয়তা দূর করে।

তবে আমার দৃষ্টিতে, কোনও পরিষেবা তার ইউআরআই কাঠামোর চেয়ে অনেক বেশি। এটি কার্যকরভাবে ব্যবহার করতে, আপনার আরও জানতে হবে:

• আপনি কী ক্যোয়ারী প্যারামিটারগুলি ব্যবহার করতে পারেন এবং তাদের সম্ভাব্য মানগুলি
• জেএসএন / এক্সএমএল এর কাঠামো / আপনার পোষ্ট / প্যাচ / ইত্যাদি অনুরোধে আপনার যা যা ডকুমেন্ট প্রেরণ করতে হবে
• সার্ভার দ্বারা প্রেরিত প্রতিক্রিয়ার কাঠামো
• সম্ভাব্য ত্রুটিগুলি ঘটতে পারে
• ...

উপরের উপর ভিত্তি করে, HATEOAS কেবল আবিষ্কার এবং মিলনের সমস্যাগুলির একটি ক্ষুদ্র ভগ্নাংশ সমাধান করে। আপনাকে এখনও উপরের চারটি দিকটি নথিভুক্ত করতে হবে এবং ক্লায়েন্টরা তাদের কারণে এখনও সার্ভারের সাথে দৃ strongly়ভাবে মিলিত হবে। ক্লায়েন্টদের বিরতি এড়াতে, আপনাকে এখনও আপনার এপিআই সংস্করণ করতে হবে।

এটির একমাত্র উপকারটি হ'ল আপনি নিজের URL কাঠামো আরও বা কম নির্বিঘ্নে পরিবর্তন করতে পারেন (উপায় দ্বারা, "শীতল ইউআরআই পরিবর্তন হয় না" নীতির কী হয়েছিল ?)। আমার বোধগম্যতা কি সঠিক?

Answer 1

আমি মনে করি আপনার প্রবৃত্তিগুলি মূলত সঠিক; এই ঘোষিত সুবিধাগুলি সত্যিই এত দুর্দান্ত নয়, কোনও তুচ্ছ ওয়েব অ্যাপ্লিকেশন হিসাবে ক্লায়েন্টরা শব্দার্থবিজ্ঞানগুলি কী করছে সেগুলি সিনট্যাক্সের পাশাপাশি যত্নশীল হবে।

তবে এর অর্থ এই নয় যে আপনার অ্যাপ্লিকেশনটিকে হেটোয়াসের নীতিগুলি অনুসরণ করা উচিত নয়!

HATEOAS কী সত্যিই মানে কি? এর অর্থ আপনার অ্যাপ্লিকেশনটিকে কাঠামোবদ্ধ করা যাতে এটি কোনও ওয়েব সাইটের মতো নীতিগতভাবে হয় এবং আপনি যে সমস্ত ক্রিয়াকলাপগুলি করতে চান তা কিছু জটিল স্কিমা ডাউনলোড না করেই আবিষ্কার করা যায়। (পরিশীলিত ডাব্লুএসডিএল স্কীমগুলি সমস্ত কিছু কভার করতে পারে, তবে তারা যা করার সাথে সাথে তারা কার্যত প্রতিটি প্রোগ্রামারকে বোঝার ক্ষমতা ছাড়িয়ে গেছে, একাই লিখতে দাও! আপনি এই জাতীয় জটিলতার বিরুদ্ধে প্রতিক্রিয়া হিসাবে হেটোয়াসকে দেখতে পারেন))

HATEOAS কেবল সমৃদ্ধ লিঙ্কগুলি বোঝায় না। এর অর্থ এইচটিটিপি স্ট্যান্ডার্ডের ত্রুটি প্রক্রিয়াগুলি ব্যবহার করে এর অর্থ সঠিকভাবে কী ঘটেছে তা নির্দেশ করতে; আপনাকে কেবল "ওয়াহাহ" দিয়ে প্রতিক্রিয়া জানাতে হবে না! না "এবং পরিবর্তে একটি দস্তাবেজ সরবরাহ করতে পারে যা আসলে কী ভুল ছিল এবং ক্লায়েন্ট এটি সম্পর্কে কী করতে পারে তা বর্ণনা করে। এটিও মানে সমর্থনকারী ভালো জিনিস বিকল্প অনুরোধ এবং (ক্লায়েন্ট আউট কি HTTP- র পদ্ধতি তারা ব্যবহার করতে পারেন এটি করতে সক্ষম হবেন এর আদর্শ উপায়) বিষয়বস্তুর প্রকার আপস যাতে প্রতিক্রিয়া বিন্যাস একটি ফর্ম যে ক্লায়েন্ট সব ব্যবস্থা করতে সক্ষম অভিযোজিত করা যাবে। এর অর্থ ব্যাখ্যামূলক পাঠ্য লেখা(বা সম্ভবত এটির সাথে লিঙ্ক রয়েছে) যাতে ক্লায়েন্টরা অপ্রয়োজনীয় ক্ষেত্রে সিস্টেমটি কীভাবে ব্যবহার করবেন তা সন্ধান করতে পারে যদি তারা না জানে; ব্যাখ্যামূলক পাঠ্যটি মানব পঠনযোগ্য হতে পারে বা এটি মেশিন পঠনযোগ্য হতে পারে (এবং আপনার ইচ্ছামত জটিল হতে পারে)। শেষ অবধি, এর অর্থ হ'ল ক্লায়েন্টরা লিঙ্কগুলি সংশ্লেষিত করে না (ক্যোয়ারী প্যারামিটার ব্যতীত); ক্লায়েন্টরা যদি কোনও লিঙ্ক তাদের কাছে বলে থাকে কেবল তখন তা ব্যবহার করবে।

লিঙ্কগুলির জন্য দুর্দান্ত মেমরি এবং এইচটিটিপি মানদণ্ডের একটি এনসাইক্লোপিডিক জ্ঞান সহ কোনও ব্যবহারকারী (যারা এইচটিএমএলটির পরিবর্তে জেএসএন বা এক্সএমএল পড়তে পারেন তাই) ব্যবহারকারী ব্রাউজ করার বিষয়ে আপনাকে ভাবতে হবে , তবে অন্যথায় কী করবেন তা সম্পর্কে কোনও জ্ঞান নেই না।

এবং অবশ্যই, আপনি এইচটিএমএল (5) / জেএস ক্লায়েন্ট পরিবেশন করতে সামগ্রীর ধরণের আলোচনার ব্যবহার করতে পারেন যা তাদের অ্যাপ্লিকেশনটি তাদের ব্যবহার করতে দেবে, যদি এটি তাদের ব্রাউজারটি গ্রহণ করতে প্রস্তুত থাকে। সর্বোপরি, যদি আপনার RESTful এপিআই কোনও ভাল হয় তবে এর উপরে প্রয়োগ করার জন্য এটি "তুচ্ছ" হওয়া উচিত?

Answer 2

জিনিসটি হ'ল, হেটোয়াস অবশ্যই একটি দ্বিতীয় স্তম্ভের সাথে আসতে হবে যা একটি RESTful API কী তা নির্ধারণ করে: মানসম্পন্ন মিডিয়া টাইপ। রায় ফিল্ডিং নিজেই ড

একটি REST এপিআই এর সম্পদ প্রতিনিধিত্ব করার জন্য ব্যবহৃত মিডিয়া ধরণের (গুলি) সংজ্ঞায়িত করতে তার বর্ণনামূলক প্রচেষ্টার প্রায় সমস্ত ব্যয় করা উচিত "।

স্ট্যান্ডার্ডাইজড মিডিয়া টাইপের সাহায্যে রূপান্তরটি স্পষ্টভাবে সংজ্ঞায়িত করা হয় এবং একে অপরের দিকে সংস্থানকে নির্দেশ করতে হাইপারটেক্সট, আপনি এমন একটি সংস্থান গ্রাফ তৈরি করতে পারেন যা কোনও ক্লায়েন্টকে না ভেঙে কোনও রূপ নিতে পারে। ওয়েব ওয়ার্কের মতো, সত্যই: আপনার নথির মধ্যে লিঙ্ক রয়েছে এবং নথিতে এইচটিএমএল লেখা আছে যা কীভাবে এই লিঙ্কগুলি অনুসরণ করবেন তা নির্ধারণ করে। <a href>জিইটি, <form>জিইটি বা পোষ্ট (এবং জিইটি ক্ষেত্রে ইউআরএল টেমপ্লেট সংজ্ঞায়িত করা), <link type="text/css">হ'ল জিইটি ... ইত্যাদি brow ব্রাউজারগুলি এভাবে নির্বিচার কাঠামোগত এইচটিএমএল পৃষ্ঠা এবং ওয়েবে নেভিগেট করতে পারে।

আপনি তৈরি সমস্ত পয়েন্ট

• আপনি কী ক্যোয়ারী প্যারামিটারগুলি ব্যবহার করতে পারেন এবং তাদের সম্ভাব্য মানগুলি
• জেএসএন / এক্সএমএল এর কাঠামো / আপনার পোষ্ট / প্যাচ / ইত্যাদি অনুরোধে আপনার যা যা ডকুমেন্ট প্রেরণ করতে হবে
• সার্ভার দ্বারা প্রেরিত প্রতিক্রিয়ার কাঠামো
• সম্ভাব্য ত্রুটিগুলি ঘটতে পারে

এমন পয়েন্টগুলি যা আপনার মানসম্পন্ন মিডিয়া ধরণের সংজ্ঞা দ্বারা সজ্জিত হওয়া উচিত । অবশ্যই এটি বেশ শক্ত এবং এমন কিছু নয় যা বেশিরভাগ লোকেরা যখন "REST" এপিআই সংজ্ঞায়িত করেন তখন সে সম্পর্কে ভাবেন। আপনি কেবলমাত্র ব্যবসায়িক প্রতিষ্ঠানগুলি নিতে পারবেন না এবং একটি বিশ্রামপ্রাপ্ত এপিআই রাখার জন্য তাদের বৈশিষ্ট্যগুলি JSON নথিতে স্থানান্তর করতে পারবেন না।

অবশ্যই, যা ঘটেছিল তা হল "জটিল এসওপি আইটেমির পরিবর্তে এইচটিটিপি ব্যবহার করুন" বোঝাতে একরকম পাতলা হয়ে গেছে। কেবলমাত্র এইচটিটিপি এবং হাইপারটেক্সট ব্যবহার করা বিশ্রামের পক্ষে যথেষ্ট নয়, বেশিরভাগ লোকেরই এটি ভুল হয়ে যায়।

এটি যে কোনও খারাপ জিনিস প্রয়োজন তা নয়: দীর্ঘমেয়াদে রক্ষণাবেক্ষণ এবং বিকাশতার বিনিময়ে কর্মক্ষমতা এবং বিকাশের স্বাচ্ছন্দ্য দিন RE এটি বড় এনট্রিপ্রাইজ অ্যাপ্লিকেশন সংহতকরণের জন্য তৈরি হয়েছিল। হার্ড-কোডেড জেএসওএন কাঠামোযুক্ত একটি ছোট ওয়েব এপিআই আপনার প্রয়োজন হতে পারে। এটিকে কেবল REST বলবেন না, এটি একটি অ্যাড-হক ওয়েব এপিআই, আরও কিছু নয়। এবং এর অর্থ এই নয় যে এটি স্তন্যপান করছে, এর অর্থ কেবল এটি রেস্টের সীমাবদ্ধতা অনুসরণ করার চেষ্টা করে না।

আরও পড়া

• http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
• http://martinfowler.com/articles/richardsonMaturityModel.html

আশা করি এই সাহায্যটি কিছুটা স্পষ্ট করবে :)

Answer 3

কিছু হাইপারমিডিয়া ফর্ম্যাট রয়েছে যা আরও উন্নত প্রতিক্রিয়া সরবরাহ করার চেষ্টা করে যার মধ্যে কী ধরনের অনুরোধগুলি প্রেরণ করা হবে সে সম্পর্কে আরও তথ্য অন্তর্ভুক্ত রয়েছে এবং আরও তথ্যের সাহায্যে প্রতিক্রিয়াটিকে সমৃদ্ধ করতে আপনাকে কিছুই থামছে না।

এখানে সিরেন ডকুমেন্টের একটি উদাহরণ রয়েছে :

{
  "class": [ "order" ],
  "properties": { 
      "orderNumber": 42, 
      "itemCount": 3,
      "status": "pending"
  },
  "entities": [
    {
      "class": [ "info", "customer" ],
      "rel": [ "http://x.io/rels/customer" ], 
      "properties": { 
        "customerId": "pj123",
        "name": "Peter Joseph"
      },
      "links": [
        { "rel": [ "self" ], "href": "http://api.x.io/customers/pj123" }
      ]
    }
  ],
  "actions": [
    {
      "name": "add-item",
      "title": "Add Item",
      "method": "POST",
      "href": "http://api.x.io/orders/42/items",
      "type": "application/x-www-form-urlencoded",
      "fields": [
        { "name": "orderNumber", "type": "hidden", "value": "42" },
        { "name": "productCode", "type": "text" },
        { "name": "quantity", "type": "number" }
      ]
    }
  ],
  "links": [
    { "rel": [ "self" ], "href": "http://api.x.io/orders/42" },
    { "rel": [ "previous" ], "href": "http://api.x.io/orders/41" },
    { "rel": [ "next" ], "href": "http://api.x.io/orders/43" }
  ]
}

যেমন আপনি দেখতে পাচ্ছেন, কীভাবে সম্পর্কিত কল করতে হবে সম্পর্কিত তথ্য actionsবার্তায় সরবরাহ করা হয় এবং তারপরে এই তথ্যের ব্যাখ্যা দিয়ে ক্লায়েন্ট পরিবর্তনের জন্য আরও প্রতিরোধী হয়ে ওঠে।

এটি বিশেষত শক্তিশালী হয়ে ওঠে যদি relগুলি ইউআরআই থাকে তবে নির্দিষ্ট শব্দভাণ্ডারের পরিবর্তে সন্ধান করা যেতে পারে।

Answer 4

আপনি কোথায় পড়েছেন যে HATEAOS পরিষেবাদিগুলির জন্য "ডকুমেন্টেশনগুলির আর দরকার নেই"? যেমনটি আপনি বলেছেন, আপনার এখনও লিঙ্কগুলির শব্দার্থবিজ্ঞান ডকুমেন্ট করতে হবে। তবে HATEOAS এর সাথে আপনার ডকুমেন্ট করার দরকার নেই, এবং তাই চিরতরে রাখুন, বেশিরভাগ ইউআরআইয়ের কাঠামো।

HATEOAS কোনও পরিষেবা প্রয়োগকারীকে ক্লায়েন্ট নির্ভর করে এমন একটি ইউআরআইয়ের একটি ছোট সেট পরিবর্তন না করেই কার্যকরভাবে এবং দক্ষতার সাথে প্রয়োগটি পরিবর্তন এবং স্কেল করতে দেয়। বড় সংখ্যার চেয়ে কম সংখ্যক এন্ট্রি পয়েন্ট অপরিবর্তিত রাখা সহজ is সুতরাং, পরিষেবাটিতে সর্বজনীন এন্ট্রি পয়েন্টগুলির সংখ্যা হ্রাস করা এবং উপ-সংস্থাগুলিতে গতিশীলভাবে লিঙ্কগুলি সরবরাহ করা (HATEOAS) আসলে "কুল ইউআরআইগুলি পরিবর্তন করে না" সমর্থন করে হ্যাটোওএএস পরিষেবাগুলির চেয়ে ভাল।

Comments

একটি জায়গা যেখানে কেউ পড়তে পারেন যে "ডকুমেন্টেশন আর প্রয়োজন হয় না" হলেন রায় ফিল্ডিংয়ের প্রবন্ধ যা এই শব্দটি তৈরি করেছিলেন।

— মেরিটন -

আমি "ডকুমেন্টেশন" ব্যবহারের জন্য ফিল্ডিংয়ের গবেষণামূলক প্রবন্ধটি সন্ধান করেছি এবং "ডকুমেন্টেশনের আর প্রয়োজন নেই" উক্তিটির অনুরূপ কিছুই খুঁজে পাওয়া যায়নি। ফিল্ডিংয়ের গবেষণামূলক প্রবন্ধে আপনি কোথায় এই দাবীটি পেয়েছেন তা দয়া করে চিহ্নিত করতে পারেন?

— জোনাথন গিডি

Answer 5

(HATEOAS), একটি ওয়েব এপিআই "সত্যই বিশ্রামযুক্ত" করার দাবি করা হয়েছে এমন প্রতিবন্ধকতা

কেবলমাত্র এটিই সত্যিকারের REST এপিআই তৈরি করে কেবলমাত্র একটিমাত্র নয়, সমস্ত প্রতিবন্ধকতাগুলি পূরণ করছে।

তবে আমার দৃষ্টিতে, কোনও পরিষেবা তার ইউআরআই কাঠামোর চেয়ে অনেক বেশি। এটি কার্যকরভাবে ব্যবহার করতে, আপনার আরও জানতে হবে: ...

এজন্য আমাদের অন্যান্য সীমাবদ্ধতা, স্ব-বর্ণনামূলক বার্তা ইত্যাদি প্রয়োজন ...

ক্লায়েন্টদের বিরতি এড়াতে, আপনাকে এখনও আপনার এপিআই সংস্করণ করতে হবে।

আপনি কীভাবে চেষ্টা করেন তা আপনার API এর সংস্করণ করা দরকার। একটি আরআরএসএফ ক্লায়েন্টে আপনাকে এখনও এমন কোনও পৃষ্ঠায় কীভাবে পৌঁছাতে হবে যেখানে আপনি স্টাফগুলি করতে চান, কোন লিঙ্কটি অনুসরণ করতে হবে এবং বার্তাটি বর্ণনা করে আরডিএফ ভোকাবের উপর ভিত্তি করে আপনাকে কোন সম্পত্তি সংগ্রহ করতে হবে তা জানতে হবে। যদি আপনাকে সেই ভোকাব থেকে কোনও জিনিস প্রতিস্থাপন বা অপসারণ করতে হয়, তবে এটি সম্ভবত আপনার সমস্ত ক্লায়েন্টকে ভেঙে ফেলবে এবং আপনার একটি নতুন সংস্করণ প্রয়োজন। সুতরাং আমি মনে করি REST এমন কিছু নয় যা আপনার তাড়াতাড়ি প্রকাশ করা উচিত (এবং আপনি নিয়মিত এপিআই পরিবর্তন করার সময় মডেলটি সন্ধান করুন), অন্যথায় আপনার অনেকগুলি সংস্করণ থাকবে। প্রথমে আপনি স্থিতিশীল ডোমেন মডেলটি তৈরি করতে পারেন যা আপনি তৈরি করতে পারেন ...