ক্যোয়ারী প্যারামিটারগুলির দীর্ঘ তালিকা সহ [RESTFULL] কোয়েরি API নকশা করুন [বন্ধ]


153

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

পরামিতিগুলির সংখ্যা হ্রাস করা কোনও বিকল্প নয়।

আমি যে বিকল্পের কথা ভাবতে পারি তা হ'ল ইউআরআইতে পোষ্ট পদ্ধতিটি ব্যবহার করা এবং পোষ্ট বডিটির অংশ হিসাবে ফিল্টারগুলি প্রেরণ করা। এটি কি RESTfull হওয়ার বিরুদ্ধে (ডেটা ক্যোয়ারিতে পোস্ট করার জন্য কল করা)।

কারও কি আরও ভাল ডিজাইনের পরামর্শ আছে?


2
সংক্ষিপ্ত (1-চর ইত্যাদি) প্যারামিটারের নাম ব্যবহার করবেন?
ম্যাডব্রেকস

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

ধন্যবাদ। এই প্রশ্নটি বন্ধ থাকা সত্ত্বেও এটি আমার কাছে ঠিক উত্তর হওয়া দরকার। আপনি খুশি আমি খুশি।
কেসি ক্রুকস্টন

উত্তর:


142

মনে রাখবেন যে একটি REST এপিআই সহ, এটি আপনার দৃষ্টিভঙ্গির সমস্ত প্রশ্ন।

একটি আরএসটি এপিআইতে দুটি মূল ধারণা হ'ল শেষ পয়েন্ট এবং সংস্থানসমূহ (সত্তা)। আলগাভাবে বলতে গেলে, একটি এন্ডপয়েন্টটি হয় হয় জিইটি এর মাধ্যমে রিসোর্স দেয় বা POST এবং PUT এর মাধ্যমে রিসোর্স গ্রহণ করে এবং ততক্ষণে (বা উপরের সংমিশ্রণে)।

এটি স্বীকৃত যে POST- এর মাধ্যমে আপনি যে ডেটা প্রেরণ করেছেন তার ফলে নতুন সংস্থান এবং এর সাথে সম্পর্কিত এন্ডপয়েন্ট (গুলি) তৈরি হতে পারে বা নাও হতে পারে, যা সম্ভবত পোষ্টড ইউআরএলের অধীনে "লাইভ" থাকবে না। অন্য কথায় আপনি যখন পোস্ট করেন আপনি পরিচালনা করার জন্য কোথাও ডেটা প্রেরণ করেন। POST এন্ডপয়েন্টটি এমন নয় যেখানে সাধারণত সাধারণত সংস্থানটি পাওয়া যায় be

আরএফসি 2616 এর উদ্ধৃতি (অপ্রাসঙ্গিক অংশ বাদ দেওয়া, এবং প্রাসঙ্গিক অংশ হাইলাইট করা সহ):

9.5 পোস্ট

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

  • ...
  • ডেটা হ্যান্ডলিং প্রক্রিয়াতে কোনও ফর্ম জমা দেওয়ার ফলাফল হিসাবে ডেটাগুলির একটি ব্লক সরবরাহ করা;
  • ...

...

পোস্ট পদ্ধতি দ্বারা সম্পাদিত ক্রিয়াকলাপের ফলে এমন কোনও সংস্থান দেখা যায় না যা কোনও ইউআরআই দ্বারা চিহ্নিত করা যায় । এই ক্ষেত্রে, 200 (ঠিক আছে) বা 204 (কোনও বিষয়বস্তু নয়) উপযুক্ত প্রতিক্রিয়ার স্থিতি, প্রতিক্রিয়ার ফলাফলটি বর্ণনা করে এমন কোনও সত্তা অন্তর্ভুক্ত কিনা তা নির্ভর করে ।

যদি উত্স সার্ভারে কোনও উত্স তৈরি করা হয় তবে প্রতিক্রিয়াটি 201 হওয়া উচিত (তৈরি করা) ...

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

নিম্নলিখিত উদাহরণ বিবেচনা করুন:

GET    /books?author=AUTHOR
POST   /books
PUT    /books/ID
DELETE /books/ID

এটি একটি সাধারণ REST CRUD। তবে আমরা যদি যোগ করি তবে:

POST /books/search

    {
        "keywords": "...",
        "yearRange": {"from": 1945, "to": 2003},
        "genre": "..."
    }

এই শেষ পয়েন্টটি সম্পর্কে অ-রেস্টস্টুলের কিছুই নেই। এটি অনুরোধের বডি আকারে ডেটা (সত্তা) গ্রহণ করে। সেই ডেটা হ'ল অনুসন্ধানের মানদণ্ড - অন্য যে কোনও ডিটিও। এই শেষ পয়েন্টটি অনুরোধের প্রতিক্রিয়া হিসাবে একটি সংস্থান (সত্তা) উত্পাদন করে: অনুসন্ধান ফলাফল । অনুসন্ধানের ফলাফলগুলির সংস্থানটি একটি অস্থায়ী যা ক্লায়েন্টের সাথে সাথে পুনঃনির্দেশ ছাড়াই এবং অন্য কোনও ক্যানোনিকাল ইউআরএল ছাড়াই সরবরাহ করা হয়।

এটি এখনও বিশ্রামযোগ্য, সত্তাগুলি বই না হয়ে ব্যতীত - অনুরোধ সত্তাটি বই অনুসন্ধানের মানদণ্ড, এবং প্রতিক্রিয়া সত্তা হ'ল বইয়ের অনুসন্ধানের ফলাফল results


আপনি কি ডিটিওর জন্য সম্মেলনগুলির নামকরণের কয়েকটি শ্রেণির পরামর্শ দিতে পারেন?
কাওয়াদজ

ব্যক্তিগতভাবে আমি সাথে যেতে হবে BooksSearchCriteriaDTOএবং BooksSearchResultsDTO
আমির আবিরি

এই ক্ষেত্রে পোষ্ট / বই / সন্ধানের জন্য সেরা এইচটিটিপি প্রতিক্রিয়া কোডটি কী হবে? 201 এখনও প্রয়োগ হয়?
এল। হল্যান্ডা

9
201 এর বিপরীত - এটি বোঝায় যে একটি উত্স তৈরি করা হয়েছে। এমন একটি উত্স যার প্রত্যাশা রয়েছে যে এটির কোথাও অনন্য ইউআরআই রয়েছে। 201 টি উপযুক্ত যখন POSTসিআরইউডির সি অংশের জন্য ব্যবহৃত হয়। আমি খালি সন্ধানের ফলাফলের জন্য প্লেইন পুরানো 200 এর সাথে যেতে পারব, বিকল্পভাবে 204 সহ।
আমির আবির

@ আমিরআবিরী আপনাকে অনেক ধন্যবাদ
মোহাম্মদ-মুহিরি

84

অনেক লোক এই অনুশীলনটি গ্রহণ করেছে যে খুব দীর্ঘ বা খুব জটিল একটি জিইটি একটি কোয়েরি স্ট্রিং (যেমন ক্যোয়ারী স্ট্রিংগুলি খুব সহজে নেস্টেড ডেটা পরিচালনা করে না) পরিবর্তে একটি পোষ্ট হিসাবে প্রেরণ করা যেতে পারে, দেহে জটিল / দীর্ঘ তথ্য উপস্থাপন করা হয় অনুরোধের।

এইচটিটিপি অনুমানে পোষ্টের জন্য চেকটি দেখুন। এটি অবিশ্বাস্যভাবে বিস্তৃত। (আপনি যদি বিশ্রামের একটি লুফোলের মাধ্যমে যুদ্ধযাত্রা চালাতে চান ... পোষ্টটি ব্যবহার করুন))

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

(লম্বা দীর্ঘ ডিগ্রেশন ... আমি সম্প্রতি আবিষ্কার করেছি যে এইচটিটিপি অনুমানের দ্বারা জিইটি একটি নথির বডি ধারণ করতে পারে There এখানে একটি বিভাগ রয়েছে যা বলে, প্যারাফ্রেসিং, "এই বিভাগে তালিকাবদ্ধ বিষয়গুলি বাদ দিয়ে কোনও অনুরোধে একটি ডকুমেন্ট বডি থাকতে পারে" ... এবং যে বিভাগটি এটি উল্লেখ করেছে এটি কোনও তালিকাবদ্ধ করে না I এইচটিটিপি লেখকরা যে বিষয়ে কথা বলছিলেন সেখানে আমি একটি থ্রেড সন্ধান করেছি এবং এটি ইচ্ছাকৃত, যাতে রাউটারগুলি এবং এই জাতীয় বার্তাগুলির মধ্যে পার্থক্য না করতে হয় However তবে, অনেকগুলি অবকাঠামোগত টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টানা শরীরের উপস্থাপন ফিল্টারগুলি সহ, যেমন আপনি পোস্টের মতো পেতে পারেন তবে আপনি পাশা ঘূর্ণায়িত হবেন))


11
বডি সহ HTTP GET সম্পর্কে আরও আলোচনার জন্য এই প্রশ্নটি দেখুন ।
রিকিয়া

6

সংক্ষেপে: একটি পোস্ট করুন তবে এক্স-এইচটিটিপি-পদ্ধতি-ওভাররাইড শিরোনাম ব্যবহার করে ওভাররাইড HTTP পদ্ধতিটি ।

বাস্তব অনুরোধ

পোষ্ট / বই

সত্তা দেহ

title "শিরোনাম": "ইপসাম", "বছর": 2017

শিরোলেখ

এক্স-এইচটিটিপি-পদ্ধতি-ওভাররাইড: জিইটি

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

এইভাবে আপনি আরএসটি নীতিগুলির সাথে সামঞ্জস্য রেখে নকশাটি রাখেন।

সম্পাদনা: আমি জানি যে এই সমাধানটি মূলত কিছু ব্রাউজার এবং সার্ভারগুলিতে প্যাচটিচ ক্রিয়া সমস্যা সমাধানের উদ্দেশ্যে করা হয়েছিল তবে এটি একটি দীর্ঘ ইউআরএল-এর ক্ষেত্রে জিইটি ক্রিয়া সহ আমার পক্ষে কাজ করে যা প্রশ্নের বর্ণনায় বর্ণিত সমস্যা।


2
IETF অননুমোদিত এক্স পূর্বে সমাধান HTTP- র হেডার: tools.ietf.org/html/rfc6648
jannis


@ জজনিস আপনি যে আরএফসি লিঙ্ক করেছেন তাতে 1.4 থাকে। এটি বিদ্যমান X-অপসারণ এবং 1.5 সম্পর্কে কোনও সুপারিশ করে না । এটি বিদ্যমান স্পেসিফিকেশনগুলিকে ওভাররাইড করে না। ... X-আইএমও এখানে থাকবে?
জান মোলনার

-3

আপনি যদি জাভা এবং জ্যাক্স-আরএসে বিকাশ করে থাকেন তবে আমি আপনাকে @ জিইটি দিয়ে @ কোয়েরিপ্যারাম ব্যবহার করার পরামর্শ দিচ্ছি

আমার যখন একই তালিকার মধ্য দিয়ে যাওয়ার দরকার ছিল তখন আমার একই প্রশ্ন ছিল।

উদাহরণ দেখুন:

import java.util.List;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.QueryParam;
import javax.ws.rs.core.Response;

@Path("/poc")
public class UserService {

    @GET
    @Path("/test/")
    @Produces(MediaType.APPLICATION_JSON)
    public Response test(@QueryParam("code") final List<Integer> code) {
                Integer int0 = codigo.get(0);
                Integer int1 = codigo.get(1);

        return Response.ok(new JSONObject().put("int01", int0)).build();
    }
}

ইউআরআই প্যাটার্ন: "পোকা / পরীক্ষা? কোড = 1 এবং কোড = 2 এবং কোড = 3

@ কোয়েরিপ্যারাম ক্যোয়ারী প্যারামিটারটিকে "অর্ডারবি = বয়স এবং অর্ডারবি = নাম" java.util.Chell এ স্বয়ংক্রিয়ভাবে রূপান্তর করবে।


আপনার উদাহরণটি ব্যাখ্যা করলে ভাল হবে। এটি কোন প্রোগ্রামিং ভাষায় লেখা আছে?
আলেকস আন্দ্রেভ

হাই @ অ্যালেক্সআন্দ্রিভ তোমার মতামত এর জন্য ধন্যবাদ। ভাল হয়েছে? tks
acacio.martins

এই প্রশ্নটি RESTful পরিষেবার নকশা সম্পর্কে, বাস্তবায়ন সম্পর্কে নয়। এই উত্তরটি প্রশ্নের উত্তর দেয় না।
হেরেটিক বানর

@ ব্যবহারকারী 1331413 IMHO হ্যাঁ, এখন এটি আরও ভাল। আপনার প্রচেষ্টার জন্য আপনাকে ধন্যবাদ .. তবে মাইক ম্যাককাগান যেমন বলেছিলেন, প্রশ্ন বাস্তবায়নের পরিবর্তে আরআরইএসটি ধারণা সম্পর্কে
আলেকস অ্যান্ড্রিভ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.