xml-rpc

[Cyrus_black]

با سلام خدمت دوستان

من یک سوال دارم

این xml-rpc رو یکی میشه دقیق توضیح بده ؟

من چندین مورد خوندم به جایی نرسیدم

دقیقا نفهمیدم یه نوع کد نویسی(شبه زبان هست ) یا خیر

مثل یه پروتکل عمل میکنه

مثلا ibsng که ازxml-rpc استفاده میکنه با خود php باید کد زده بشه یا از زبان دیگه ای ?xml-rpc

[eshpilen]

پروتکله دیگه.
پروتکلی برای فراخوانی توابعی در روی سرور و گرفتن نتیجهء فراخوانی.
مثلا چند تا پارامتر رو به یک تابع روی سایت من پاس میکنید و یک جواب از نوع عددی رشته ای هرچی ازش میگیرید.
این پروتکل برای استاندارد کردن روش انجام و فرمت ارسال و دریافت این کار طراحی شده.
ولی تاجاییکه میدونم قدیمیه و استانداردهای جدیدتری جاش اومدن.
XML-RPC، REST، SOAP
اینا همشون کاربردهای کم و بیش مشابهی دارن.
هرکدام مزایا و معایبی دارن و قدیم و جدید دارن و فرمت و پروتکل متفاوتی.
همش هم سر استانداردسازی بوده.
البته زیاد گول تعدد و گستردگی و پیچیدگی اینها رو نخورید. اصلا خیلی ها میگن زیادی این پروتکل ها رو پیچیده و حجیم درست کردن. یعنی در بیشتر کاربردها به اینقدر پیچیدگی و جزییات نیازی نیست. مثلا REST که ساده تره خیلی جاها ترجیح داده شده.
همهء حرف و هدف اینا هم استانداردسازی نحوهء استفاده از سرویسهای مختلف روی وب است.
یعنی هرکس نیاد واسه خودش یه فرمت و روش و استانداردی تعریف کنه که وقتی برنامه نویسان و افراد و شرکتهای دیگه میخوان ازش استفاده کنن مجبور باشن کل مستندات رو بخونن (شاید هم مستندات درست و حسابی نداشته باشه اصلا) و کلی تست و کدنویسی کنن که مثلا بتونن از فلان سرویس و فرمت دیتای فلانی استفاده کنن!
خب ما یک فرمت و استاندارد کلی اگر داشته باشیم، هرکس میتونه سرویس و دیتای خودش رو در قالب اون تعریف کنه، و نتیجتا موقع گسترش و تعامل با دیگران کار خیلی راحتتر میشه. همه میتونن از کتابخانه ها و API های مشترکی برای این کار استفاده کنن.
مثل HTML که همه دیتا و اطلاعات و ساختار خودشون رو باهاش میسازن. حالا میشد مثلا طراحان هر مرورگری بیان یه زبان و ساختار و استاندارد خاص مرورگر خودشون طراحی کنن، ولی نتیجش چی میشد؟ آیا باعث اتلاف وقت و انرژی زیاد و ناسازگاری و مشکلات عدیده نمیشد؟
البته بحث سرویسهای وب اونقدر هم حاد نیست! بنظرم عملا اونقدری کاربردهای گسترده بر اساس وب سرویسها پیش نیامدن و افراد و شرکتها هم مواردی که بخوان به شکل سرویسهای وب با هم ارتباط و تعامل داشته باشن کمتر از حدی که شاید بعضیا فکر میکردن داشتن و دارن. و هنوزم خیلی ها از روشها و الگوریتم و فرمتی که خاص خودشون طراحی کردن استفاده میکنن که اغلب خیلی ساده تر از این استانداردها هستن. مثلا ممکنه سرویس من اینطوری باشه که در یک پارامتر GET یا POST اسم یک کاربر رو به برنامهء روی سرور ارسال میکنم و برنامهء روی سرور درصورت وجود چنان شخصی شمارهء id رکورد اون شخص رو برگشت میده. دیگه نه از XML استفاده میکنم نه هیچ بند و بساط دیگری. صرفه یک رشته رو در یک پارامتر درخواست HTTP ارسال میکنم و یک رشتهء رو بعنوان پاسخ میگیرم. اینطوری از نظر کدنویسی و غیره راحتتر و سریعتره تا اینکه مثلا بخوام بخاطر این تک کاربرد ساده و خاص خودم یک وب سرویس راه بندازم و این اطلاعات ساده و محدود رو موقع ارسال و دریافت در یک فرمت دیگه مثل XML درج کنم بین تگهایی با حجم و اطلاعات افزوده.

ولی اگر ده ها و صدها سایت دیگه از این سرویس من استفاده میکردن، و اونوقت من خواستم این سرویس رو گسترش بدم و امکانات و اطلاعات دیگری هم بهش اضافه کنم، اونوقت شاید ببینم که اون روش و استاندارد قبلی من مناسب و سازگار با نیازهای جدید و اطلاعات افزوده نیست و مجبورم تغییرش بدم، در نتیجه اون ده ها و صدها استفاده کنندهء دیگر به مشکل میخورن و باید استاندارد جدید من رو بگیرن و بخونن و تمام کدهاشون رو ویرایش کنن. درحالیکه اگر از یک پروتکل استاندارد که امکانات کاملی داره استفاده کرده بودم، به احتمال خیلی زیاد نیاز به هیچ تغییری نبود یا نهایت تغییر فقط در یکی دوتا اسم و پارامتر بود برای دیگران، و همچنین برای خودم هم نیاز به کدنویسی و تغییرات خیلی کمتری داشت.

خب البته من خودمم با اینا تاحالا کار نکردم! اما قبلا بارها درموردشون مقاله هایی خونده بودم (بخصوص مقاله های ویکیپدیا).
تاجاییکه میتونستم و فکر میکردم برای روشن شدن اصل قضیه مفید باشه براتون گفتم. امیدوارم مفید واقع شده باشه و اگر بحث و اطلاعات بیشتری هم مطرح بشه تا درصورت امکان چیز بیشتری یاد بگیریم که چه بهتر.

[eshpilen]

ببین مثلا شما میخوای یک آرایه ای از اطلاعات رو در پاسخی که یک سرویس ارسال میکنه برگشت بدی.
XML-RPC میگه فرمت (این بخش از) پاسخ باید به این شکل باشه:

<array>
<data>
<value><i4>1404</i4></value>
<value><string>Something here</string></value>
<value><i4>1</i4></value>
</data>
</array>
این یعنی استاندارد کردن.
طرف مقابل وقتی مثلا در زبان ASP.NET یا جاوا یا هر زبان دیگری با کتابخانهء مخصوص XML-RPC به سرویس شما وصل میشه و پاسخ رو دریافت میکنه، نیازی نداره بدونه فرمت شما برای برگشت دادن یک مقدار آرایه ای چیه، چون این رو کتابخانهء مورد نظر خودش میدونه و انجام میده و دیتای مورد نظر رو توسط متدهایی که داره یا بصورت مقدار برگشتی که برگشت میده در محیط زبان مورد نظر در قالب آرایه های اون زبان ارائه میده.

اما یوقت هست شما از پروتکل و فرمت استانداردی استفاده نکردی. مثلا اومدی همینطور مقدارها رو پشت سرهم گذاشتی و با یک رشته ای مثل :*: اونا رو از هم جدا کردی. شاید کلیدها و مقدارها رو همینطوری پشت سر هم آوردی، مثلا به این شکل:

key1:*:value1:*:key2:*:value2:*: ...
حالا یکی دیگه ممکنه از یک روش دیگه ای استفاده کرده باشه.
خلاصه هرکس بنا به نظر و فرمتی که خودش تعریف کرده.
حالا دیگران مجبورن بیان فرمت درخواست و پاسخ و دیتای شما رو بررسی کنن و متناسب با اون کدبنویسن براش. یه کدی باید بنویسه که این مقدارها رو از هم جدا کنه و بعد به شکل آرایه دربیاره.
درحالیکه اگر شما از یک پروتکل استاندارد استفاده کرده بودی، دیگران فقط نیاز داشتن اسم تابع و مشخصات پارامترهاش و مقدار برگشتی اون رو بدونن و براحتی با کتابخانه ها و API استاندارد میتونستن با سرویس شما ارتباط برقرار کنن و نیاز به حداقل یادگیری و کدنویسی رو داشتن برای این کار.

خوب توضیح دادم؟ :چشمک:

ویرایش: البته فرمتی که در بالای پست آوردم ظاهرا مربوط به آرایه ای بدون کلید است (کلیدها عددی هستن و از صفر شروع میشن، ولی اون فرمت من درآوردی برنامه نویس که مثال زدم از نوع آرایهء کلیددار است یا شبیه رکورد و شیء و غیره.

[eshpilen]

JSON-RPC هم داریم: http://en.wikipedia.org/wiki/JSON-RPC
اومده بجای اینکه اطلاعات رو در فرمت XML تبادل کنه، در فرمت JSON تبادل میکنه.
البته لزوما تفاوتش فقط این نیست. شاید بعضی جزییات دیگرش هم فرق کنه با XML-RPC.
حالا مثال زدم فقط برای اینکه بگم اینها هیچ چیز خاصی نیستن. فقط فرمت ارسال و دریافت اطلاعات رو مشخص میکنن و بقیهء جزییات درگیر رو.
جزییات دیگه مثلا چی؟
مثلا وقتی اجرای عملیات در سمت سرور با خطا مواجه میشه، چی برگشت داده میشه، رخداد خطا چطور به اطلاع کلاینت میرسه؟ پس اینم باز نیاز به استانداردسازی داره. همینطور که نمیشه هرکس یجور عمل کنه. مثلا یکی ممکنه یک کد عددی رو بعنوان خطا برگشت بده، چون مقداری که سرویسش برگشت میده درصورتی که با خطا مواجه نشه هیچوقت یک عدد نیست. حالا سرویس یکی دیگه ممکنه مقدارهای نرمالی که برگشت میده عددی باشن (یا عدد هم توشون باشه) و بنابراین نمیتونه از برگشت دادن یک عدد بعنوان اطلاع رخداد خطا به کلاینت استفاده کنه. یکی شاید بیاد و یک رشتهء رندوم طولانی ولی فیکس شده رو بعنوان مشخص کردن خطا برگشت بده. خلاصه هرکس و هر برنامه ای برای خودش یک سازی میزنه و دیگران باید برای تشخیص خطای سرویس هرکس بیان و فرمت اون رو بخونن و یاد بگیرن و براش کد جداگانه بنویسن.
ولی در یک پروتکل استاندارد، مثلا JSON-RPC، از یک پارامتر و فرمت مشخص برای اعلام خطا استفاده میشه و بنابراین این انتخابهای سلیقه ای و موردی و مشکلات بررسی و یادگیری و کدنویسی اضافه و سفارشی بوجود نمیان و میشه برای ارتباط با همهء این سرویسها از کتابخانه و API و کدهای مشترکی استفاده کرد و درصورت نیاز تنها نیاز به تغییرات و کدنویسی های مشخص و محدودی است.

[eshpilen]

مثلا ibsng که ازxml-rpc استفاده میکنه با خود php باید کد زده بشه یا از زبان دیگه ای ?xml-rpc
بیشتر یک فرمته تا چیز دیگه.
شما پارامترهای ارسالی رو میذاری بین یکسری تگ با فرمت XML با اسم و مشخصات خاصی؛ پاسخ دریافت شده هم در همین فرمت است.
خب خودت میتونی این کار درج مقدارها در بین تگهای خاصی طبق استاندارد XML-RPC رو انجام بدی، و میتونی پاسخ دریافت شده رو هم خودت برای نتایج مورد نظر جستجو/Parse کنی با کد و توابع PHP، ولی بهتر و راحتتر اینه که از کتابخانه هایی که مخصوص این کار طراحی شدن و در PHP بصورت پیشفرض وجود دارن (بصورت اکستنشن های باینری) یا اونایی که بصورت کتابخانه های مجزا به زبان PHP هستن و میتونی دانلود و اینکلود کنی در برنامه های خودت، استفاده کنی.
خودت بخوای کد بنویسی سخته؛ باید اول پروتکل و فرمت و استانداردها رو کمی مطالعه کنی، بعدش پیاده سازیش هم راحت نیست لزوما و احتمال باگ و خطا هم توش زیاده.

میگم خدایی تاپیک رو ترکوندما :لبخند:
آخه موضوع خوبی بود از جوانب مختلف و یه جمع بندی و یادآوری واسه خودم هم شد.
باور کن وقتی توضیح میدم بعضی چیزا رو خودم تازه یاد میگیرم!!
همهء اینا رو قبلا خوندم ولی موقعی که توضیح میدم نکات کلیدی و دید جامع خوبی شکل میگیره واسه خودم هم.

[Cyrus_black]

بیشتر یک فرمته تا چیز دیگه.
شما پارامترهای ارسالی رو میذاری بین یکسری تگ با فرمت XML با اسم و مشخصات خاصی؛ پاسخ دریافت شده هم در همین فرمت است.
خب خودت میتونی این کار درج مقدارها در بین تگهای خاصی طبق استاندارد XML-RPC رو انجام بدی، و میتونی پاسخ دریافت شده رو هم خودت برای نتایج مورد نظر جستجو/Parse کنی با کد و توابع PHP، ولی بهتر و راحتتر اینه که از کتابخانه هایی که مخصوص این کار طراحی شدن و در PHP بصورت پیشفرض وجود دارن (بصورت اکستنشن های باینری) یا اونایی که بصورت کتابخانه های مجزا به زبان PHP هستن و میتونی دانلود و اینکلود کنی در برنامه های خودت، استفاده کنی.
خودت بخوای کد بنویسی سخته؛ باید اول پروتکل و فرمت و استانداردها رو کمی مطالعه کنی، بعدش پیاده سازیش هم راحت نیست لزوما و احتمال باگ و خطا هم توش زیاده.

میگم خدایی تاپیک رو ترکوندما :لبخند:
آخه موضوع خوبی بود از جوانب مختلف و یه جمع بندی و یادآوری واسه خودم هم شد.
باور کن وقتی توضیح میدم بعضی چیزا رو خودم تازه یاد میگیرم!!
همهء اینا رو قبلا خوندم ولی موقعی که توضیح میدم نکات کلیدی و دید جامع خوبی شکل میگیره واسه خودم هم.


ممنون از جمع بندی خوبت عزیز
در این صورت باید پارامتر های ارسالی xml باشه؟

چون تو ساختار که در پارس پویش برای ibsng نوشته بود هسته پایتون و پوسته php ، پس نمیشه پارامتر های ارسالی php باشه؟

[eshpilen]

در این صورت باید پارامتر های ارسالی xml باشه؟
حالا من دیگه جزییاتش رو نخوندم ولی طبیعتا خیلی چیزها یا بیشتر چیزها یا حتی تمام چیزها، توسط تگهای XML باید مشخص بشه.
مثلا میخوای مقدار رشته ای موجود در یک متغییر PHP رو بعنوان پارامتری چیزی ارسال کنی، پس احتمالا باید اینطوری فرمتش کنی:

"<string>$my_php_var</string>"
یعنی میذاری توی تگ XML مخصوص نوع داده های رشته ای.
البته این تگ هم حتما در ساختارهای تودرتوی دیگری مربوط به بقیهء اطلاعات و فرمت مخصوص XML-RPC محصور میشه؛ مثلا تگهای برونی تری که مشخص میکنن این دیتا/آرگومان باید به کدام پارامتر تابع سمت سرور پاس بشه.


چون تو ساختار که در پارس پویش برای ibsng نوشته بود هسته پایتون و پوسته php ، پس نمیشه پارامتر های ارسالی php باشه؟

دقیقا یعنی چی پارامترهای ارسالی PHP باشه؟

[eshpilen]

البته این نمونه که توضیح دادم موقعی هست که بخوای خودت همه کار رو انجام بدی. یعنی خودت در پایین ترین سطح درخواستهای XML-RPC رو بسازی و نتایج رو هم از پاسخها بیرون بکشی.
اگر از یک کتابخانهء کلاینت XML-RPC استفاده کنی قضیه میتونه خیلی تفاوت بکنه. یعنی دیگه مستقیما با این فرمت ها و تگ و این حرفا کار نداری احتمالا و صرفا از یکسری کلاس و متد مشخص برای ارتباط با سرویس مورد نظر استفاده میکنی.

[Cyrus_black]

حالا من دیگه جزییاتش رو نخوندم ولی طبیعتا خیلی چیزها یا بیشتر چیزها یا حتی تمام چیزها، توسط تگهای XML باید مشخص بشه.
مثلا میخوای مقدار رشته ای موجود در یک متغییر PHP رو بعنوان پارامتری چیزی ارسال کنی، پس احتمالا باید اینطوری فرمتش کنی:

"<string>$my_php_var</string>"
یعنی میذاری توی تگ XML مخصوص نوع داده های رشته ای.
البته این تگ هم حتما در ساختارهای تودرتوی دیگری مربوط به بقیهء اطلاعات و فرمت مخصوص XML-RPC محصور میشه؛ مثلا تگهای برونی تری که مشخص میکنن این دیتا/آرگومان باید به کدام پارامتر تابع سمت سرور پاس بشه.


دقیقا یعنی چی پارامترهای ارسالی PHP باشه؟


یعنی دیگه از xml استفاده نشه

اطلاعات فرم رو بگیریم و با همون php بفرستیم

در مورد این کلاینت xml-rpc ام یه توضیح ممنون میشم بدید

[eshpilen]

یعنی دیگه از xml استفاده نشه

اطلاعات فرم رو بگیریم و با همون php بفرستیم
خب استفاده که باید بشه، چون سرویسی که میخواید استفاده کنید با XML-RPC کار میکنه؛ اما وقتی از کتابخانه های مخصوص XML-RPC استفاده کنید دیگه نیازی ندارید خودتون XML بنویسید (یا حداقل نیاز خیلی کمتری دارید).


در مورد این کلاینت xml-rpc ام یه توضیح ممنون میشم بدید
منظورم از کلاینت همون کتابخانه هایی هستند که برای ارتباط با سرویسهای مبتنی بر XML-RPC طراحی شدن.
اطلاعات بیشتر هم ندارم چون تجربهء عملی ندارم. تاحدی که تئوریک مطالعه کردم و میدونستم و استنباط میکردم بهتون گفتم.
نباید چیزی پیچیده ای باشه. کجاش گیر کردید؟
یکم مطالعه کنید؛ مستندات سرویسی که میخواید استفاده کنید مگه در دسترس نیست؟