ایوند - Evand API

برای ورود و استفاده از سرویس کانکت، نیاز به تهیه بلیت ای از رویداد مد نظر هست. از این رو، کلاینت ها جهت بهبود و تسریع فرایند ورود نیاز به دانستن این دارن که بدونن آیا کاربر مربوطه بلیت ای از رویداد مد نظر تهیه کرده است یا خیر! در اصل بلیت های خریداری شده از ریسورس هایی در دسترس است ولی نیاز به جست و جو و فرایند هایی بسیار دشوار و طاقت فرسایی برای کلاینت ها پیش رو دارد که هر انسانی رو به گریه و زاری وا می دارد. هدف از این تسک تسهیل این امر می باشد. هدفی که در نهایت باعث شادی و خرسندی بچه های کلاینت می شود. بچه های دوست داشتنی، بچه های قوقول مقولی و نی ناش ناش. راه حل ارائه شده بدین شکل است که در صورتی که کاربر (نه مهمان) باعث بارگزاری دیتاهای مربوط به رویدادی شود (GET /events/SLUG) در بتن اطلاعات رویداد، لینکی به بلیت خریداری شده کاربر خواهد بود. این لینک در صورتی که کاربری بلیت ای از رویداد مد نظر تهیه نکرده باشد، مقداری نخواهد داشت و برابر null خواهد بود. GET https://api.evand.com/events/SLUG و خروجی بدین شکل خواهد بود: {   "data": {     "

بله، قضیه از این قرار است! قصه ای که امشب قراره براتون تعریف کنم، از نحوه کارکرد progress bar در رویدادهامون هست. هدف از وجود progress bar بر این اساس بود  که کاربر رو تشویق کنیم تا برگزار کننده هامون یه سری از قابلیت هایی که رویدادها دارن رو فعال و ازش استفاده کنن تا به این نحو بتوانیم بر کیفیت رویدادها بیفزاییم. لیست آیتم ها یه سری آیتم که الان داریمشون و قصد تشویق کاربر به استفاده ازشون داریم به این شرح است: توضیح رویداد ایمیل دعوت‌نامه همکاری در فروش تبلیغات (خرید تبلیغات وندو) لوگو و کاور سازمان رویدادها نظرسنجی آیتم هایی که برایتون لیست کردم از جمله آیتم هایی است که الان داریمشون. ممکنه برگزار کننده این آیتم ها رو پر کرده /فعال کرده باشه و یا نکرده باشه. و همچنین ترتیبی خواهند داشت به ترتیب تغریف شده نیاز به نمایششان خواهد بود. هر کدام از این آیتم ها توضیحاتی در برخواهد داشت که اینا از طرف کلاینت (فرانت/ موبایل) هامون هندل می شه. از آنجایی که در کنار توضیحات نیاز به لینک به دیگر بخش ها هست و متاسفانه بک نمی تونست درگیر تولید لینک فرانتی یا

سلام سرویس اصلی ایوند نیاز به ورودیه ای داره که بتونه رویدادهای ویژه کاربران رو از سرویس مربوطه ای دریافت بکنه. این اطلاعات همانطوری که تحویل گرفته می شه، برای استفاده های بعدی در جدول user_special_event ذخیره می شوند. برای تحویل رویدادها بدین شکل عمل می کنیم: POST http://api.evand.com/ data-providers/user-special-events Headers: Authorization: Bearer TOKEN [ { "user_id": 1, "events": [ [1, 1], [2, 0.9], [100, 0.8] ] }, { "user_id": 2, "events": [ [1, 1], [2, 0.9], [100, 0.8] ] } ] چند نکته، یک اینکه برای اینکه بتونید درخواستی ثبت کنید نیاز به اهراز هویت است و نیاز است توکن jwt تان رو از هدر ارسال نمایید. کاربر تان نیازه که دسترسی ادمین داشته باشه. دیتاهای ارسالی نیاز است بصورت آرایه ارسال شود. می تونید رویدادهایی که مربوط به یه کاربر است رو در یه درخواست جدا ارسال کنید و یا اطلاعات چندین کاربر رو همزمان ارسال کنید. هر کدام که راحت هستید قابل انجام است. اطلاعات رویدادهایی که برای یه کاربر می فرستید، ب

رویدادهای امکان ارسال نظرسنجی برای شرکت کننده گانشان را دارا می باشند. از طرفی راهی برای پاسخگویی به سوالات نظرسنجی نیاز است. هدف این مطلب توضیح، نحوه پاسخ گویی به سوالات نظرسنجی ارسال شده به شرکت کننده می باشد. برای پاسخ گویی نیاز به کد بلیت، آی دی نظرسنجی و  آی دی سوال (ها) همراه با پاسخ شان وجود دارد که نیاز است بصورت کتبی تحویل ریسورس مورد نظر شود. برای ثبت پاسخ های نظرسنجی به این شیوه عمل می کنیم: POST https://api.evand.com/surveys/ SURVEY_ID /answers { "attendee_id": " TICKET_CODE ", "questions": [ { "id": 1, "answer": ["no", "hello"] }, { "id": 2, "answer": "yes" }, { "id": 3, "answer": ["yes"] } ] } همونطور که ملاحظه می کنید، آی دی نظرسنجی (SURVEY_ID) در URI ریسورس تعیین شده است. یعنی نیازه که قرار بگیره. کد بلیت شرکت کننده (TICKET_CODE) هم در بدنه درخواست

قرار بر این است که تا ۴ رویدادی که کاربر عضو طی ۲ هفته گذشته بازدید کرده است را بصورت لیست در آورده و تقدیم حضورشان کنیم. این لیست قابلیت خالی بودن را دارا می باشد. حداکثر آیتم های موجود در این لیست ۴ تا خواهد بود ولی کمتر از این هم می تواند باشد. یعنی ۳، ۲، ۱، و هیچی. رویدادهای بازدید شده مربوط به کاربر عضو ایوند می باشد. در نتیجه نیاز است که توکن کاربر رو از طریق هدر برای ریسورس مربوطه ارسال نمایید. دریافت لیست برای دریافت لیست بدین صورت عمل می کنیم: GET https://api.evand.com/ recently-visited-events Headers: Authorization: Bearer TOKEN {     "data": [         {             "name": "event name",             "slug": "event_slug",             "city_name": "تهران",             "online": false,             "organization_name": "org name",             "organization_slug": "org_slug",             "start_date": "

یه روش دیگر برای ورود به اپ کانکت مواردی پیش می یاد که رویداد مورد نظر رو می دونیم چی هست، و موبایل شرکت کننده هم در دست هست و فقط نیازه که موبایل توسط شرکت کننده به تایید برسه تا بشه به سیستم کانکت ورود کرد. در اصل می خواهیم بدونیم شرکت کننده صاحب شماره موبایل مورد نظر هست یا نه. جهت دریافت توکن نیازه آی دی رویداد، شماره موبایل مورد نظر، و کد تاییدیه مربوط به شماره موبایل رو برای ما ارسال کنید. درخواست مورد نظر رو به این شکل برای ما ارسال می کنید: POST https://connect.evand.com/api/oauth2/token { "grant_type": " event_mobile_verification ", "client_id": "CLIENT_NAME/ID", "client_secret": "CLIENT_PASSWORD", "mobile": "9140000000", "mobile_verification_code": MOBILE_VERIFICATION_CODE, "event_id": EVENT_ID } نوع grant ای که برای این نوع ورود استفاده می شه event_mobile_verification هست و تعیین اش ضروری هست. فیلدهای client_id و client_secret

سلام یه ریسورس ای بود برای گرفتن ویجت های رویدادها بصورت مجزا از خود رویداد: GET https://api.evand.com/events/{EventSlug}/description {   "data": [     {       "title": "fsafewr",       "type": "description",       "description": "..."     },     {       "title": "werwer",       "type": "speakers",       "content": [         {           "name": "werwer"         }       ]     },     {       "title": "test",       "type": "organizers"     },     {       "content": "",       "title": "توضیحات تکمیلی",       "type": "description",       "description": "<p>این یک توضیحات تکمیلی است<\/p>"     }   ] } یه تغییری داده شده براش و اونم اینه که اگه اسلاگ رویداد

سلام دلیل ایجاد این ریسورس با اینکه ریسورس ای برای گرفتن اطلاعات رویداد داشتیم، یه سر از ضعف های موجود در نسخه قبلی بود. در نسخه قبلی در صورتی که اسلاگ رویدادی عوض می شد، خطای ۴۰۴ می داده و اینکه اشاره به اسلاگ جدید می کرد که رویداد با آدرس جدید گرفته بشه. تفاوت نسخه جدید در اینه که بجای خطای ۴۰۴، کد ۳۰۱ به منظور انتقال ریسورس به آدرس جدید می ده و آدرس ریسورس جدید هم در هدر با Location تعیین می شه. در نسخه جدید، در اصل وقتی درخواستی به اسلاگ قدیمی رویداد زده بشه، بجای اینکه خطا بده، redirect می کنه به آدرس جدید. در اصل برنامه ها یا کتابخانه هایی که باهاشون برای ارسال درخواست استفاده می کنیم، معمولا خودشون این مسئله redirect رو هندل می کنن و برنامه نویس نیاز به درگیری خاصی نخواهد بود. مثل fetch که بروبچ خودمون برای دریافت اطلاعات استفاده می کنن که خودش این مسئله redirect رو هندل می کنه. اگرم کلاینت براش مهم باشه که آدرس جدید در مرورگر به کاربر نشان بده، می تونه اسلاگی که درخواست کرده بود رو با اسلاگ رویداد دریافتی مقایسه و در صورت مغایرت می تونه کاربر رو به آدرس جد

?سلام در صفحه اول ایوند نیازه بوده که رویدادهای مربوط به موضوعاتی که کاربر علاقمند هست نمایش داده شود. از آنجایی هم که ریسورس ای برای این منظور در دست نبود، فرانت برای این منظور از ریسورس های مختلفی برای این کار استفاده می کرد که لیست موضوعات رو پیدا کنه، و برای هر موضوع درخواستی به لیست رویدادهای بزنه و رویدادهای موضوعات رو در بیاره که البته درش خطایی هم هست. درخواست هایی می خوره که نتایجی به همراه نخواهد بود. و البته ترتیب دیتاها هم به راحتی توسط فرانت قابل انجام نبود. این ریسورس برای اینکه که لیستی از موضوعات ای که کاربر بهش علاقمند هست به همراه ۴ تن از رویداد مربوط به موضوع مورد نظر رو در دسترس کلاینت قراره بده. ترتیب موضوعات هم بر اساس بیشترین فروشش چیده شده. برای دریافت لیست موضوعات و رویدادهای بدین شکل عمل می کنیم: GET https://api.evand.com/followed-categories/events {   "data": [     {       "category_id": 1,       "category_title": "کارآفرینی",       "category_slug": "کارآفرینی",    

سلام بر دوستداران علم و ادب روزی روزگاری، دخترکی، همراه با تسک پر ملاتی، دوان دوان به میدان آمد و درخواست اجرایی شدنش را داشت. داستان از این قراره که در صفحه برگزار کننده، رویدادهایی بدون نظم و ترتیب و یکی پس از دیگر در کنار هم چیده شدن و ممکنه رویداد قابل فروش ای در صفحات دیگه ای باشه در حالی که در صفحه اصلی دیده نشه و در صفحه اصلی رویداد غیرقابل فروش ای نشان بده که خوب از ایام قدیم گفته شده درسته نیست و دستور به درست شدنش صادر گردید، توسط دخترکی که دوان دوان به میدان آمده بود. ترتیب فعلی رویداد ها به شرح زیر خواهد بود: رویدادهای فعال رویدادهای بلیت تمام کرده رویدادهایی که مهلت خرید بلیت شان تمام شده است. رویدادهای تاریخ پایان گذشته رویدادهای لغو شده موارد فوق الان در ریسورسی که قراره ازش پرده برداری بشه، اعمال شده و قابل دسترسی است. برای گرفتن رویدادهای برگزار کننده به اسلاق (slug) سازمان نیاز است که در uri زیر قرار داده شود و درخواست برای گرفتن رویدادها ارسال شود: GET https://api.evand.com/organizations/{organizationSlug}/events {     "

سلام نسخه جدیدی از رویداد های مشابه ساخته و افتتاح گشت. دلیل این امر هم این بود به همزمان نیاز نباشه با فرانت جلو بریم و نسخه قبلی هم که فعلا استفاده می شه دست نخورده باقی مانده است. ساختار رویدادهای نسخه جدید هم فرق کرده و property هر رویداد به شکل وحشت ناکی کمتر شده. دلایلی هم این امر داشته که فعلا داخلش نمی شویم. برای دریافت رویدادهای مشابه، هر رویدادی به شکل زیر درخواستی می فرستیم: GET https://api.evand.com/v2/events/{eventSlug}/similar که در لینک فوق یکی eventSlug رو با اسلاگ رویداد جایگزین می کنید و هم اینکه v2 به لینک اضافه شده که با حذف اون، رویدادهای مشابه قبلی لود می شه دیتای برگشتی برای ریسورس فوق هم به این شکل خواهد بود: {     "data": [         {             "name": "دوره دفاع از شبکه-CND",             "slug": "cnd1-summer-clickpro",             "city_name": "تهران",             "online": false,             "organization_name": "کلیک پرو&