لیول 40۔ لیول کے موضوع پر انٹرویو کے سوالات کے جوابات

آئی پی ایڈریس ٹی سی پی/آئی پی پروٹوکول اسٹیک پر بنائے گئے کمپیوٹر نیٹ ورک میں نوڈ کا ایک منفرد نیٹ ورک ایڈریس ہے۔ انٹرنیٹ کو عالمی سطح پر منفرد پتوں کی ضرورت ہوتی ہے۔ مقامی نیٹ ورک پر کام کرنے کی صورت میں، نیٹ ورک کے اندر ایڈریس کی انفرادیت کی ضرورت ہوتی ہے۔ IPv4 پروٹوکول ورژن میں، IP ایڈریس 4 بائٹس لمبا ہے، اور IPv6 پروٹوکول ورژن میں، IP ایڈریس 16 بائٹس لمبا ہے۔ عام طور پر، IPv4 پروٹوکول ورژن میں ایک IP ایڈریس 0 سے 255 تک کی قدروں کے ساتھ چار اعشاریہ نمبروں کے طور پر لکھا جاتا ہے، جسے ایک ڈاٹ سے الگ کیا جاتا ہے، مثال کے طور پر، 192.168.0.3۔

ڈومین ایک ویب سائٹ کا پتہ یا ایک مخصوص زون ہے جس کا اپنا نام ہے، ڈومین نام کے نظام میں کسی دوسرے نام کے برعکس۔ ڈومین پہلی سطح، دوسری سطح، تیسری سطح، وغیرہ ہو سکتے ہیں۔ عام طور پر، پہلے درجے کا ڈومین عام صارفین کے لیے رجسٹریشن کے لیے دستیاب نہیں ہوتا ہے (پہلے درجے کے ڈومینز کی مثالیں ".ru"، ".com"، ".net" ہیں)۔ عام طور پر، تیسرے اور اس کے بعد کی سطح کے ڈومینز کو ذیلی ڈومینز کہا جاتا ہے۔
میزبان ایک مخصوص کمپیوٹر یا سرور ہوتا ہے جو مقامی یا عالمی نیٹ ورک سے منسلک ہوتا ہے۔ میزبان کا TCP/IP سروس ماحول (IP ایڈریس) میں ایک منفرد پتہ ہوتا ہے۔

حاصل کریں، پوسٹ کریں، ڈالیں، حذف کریں، آپشنز، ہیڈ، پیچ، ٹریس، لنک، ان لنک، کنیکٹ۔

GET طریقہ ایک مخصوص وسائل کے مواد کی درخواست کرنے کے لیے استعمال کیا جاتا ہے۔ POST طریقہ صارف کے ڈیٹا کو مخصوص وسائل میں منتقل کرنے کے لیے استعمال کیا جاتا ہے۔ HEAD طریقہ عام طور پر میٹا ڈیٹا کو بازیافت کرنے، وسائل کی موجودگی (URL کی توثیق) کی جانچ کرنے کے لیے استعمال کیا جاتا ہے، اور یہ دیکھنے کے لیے کہ آیا اس میں آخری بار رسائی کے بعد تبدیلی آئی ہے۔ HEAD طریقہ GET طریقہ سے ملتا جلتا ہے، سوائے اس کے کہ سرور کے جواب میں کوئی باڈی نہیں ہے۔ GET طریقہ کو POST کا ایک آسان ورژن سمجھا جاتا ہے، کیونکہ GET طریقہ مکمل درخواست کا مطلب نہیں ہے، صرف ایک URL جیسا۔

REST ایک آرکیٹیکچرل اسٹائل ہے کہ کس طرح تقسیم شدہ ایپلیکیشن اجزاء نیٹ ورک پر آپس میں تعامل کرتے ہیں۔ یہ اصطلاح رائے فیلڈنگ نے 2000 میں وضع کی تھی۔ انہوں نے ان تقاضوں کو بھی متعارف کرایا جو تقسیم شدہ درخواست کو REST فن تعمیر (ایسی ایپلی کیشنز کو RESTful بھی کہا جاتا ہے) کی تعمیل کرنے کے لیے پورا کرنا ضروری ہے۔ یہ تقاضے ہیں:

1. کلائنٹ-سرور ماڈل (مطلب یہ ہے کہ نیٹ ورک کلائنٹ اور سرور پر مشتمل ہونا چاہئے؛ سرور وہ ہے جس کے پاس وسائل ہیں، کلائنٹ وہ ہے جو ان سے درخواست کرتا ہے))
2. Отсутствие состояния (означает, что ни клиент, ни server не отслеживают состояния друг друга)
3. Кеширование (клиенты и промежуточные узлы могут кешировать результаты requestов; сооответственно, ответы serverа должны иметь явное or неявное обоmeaning, что они кешируемые or некешируемые)
4. Единообразие интерфейса (означает, что между клиентами и serverами существует общий язык взаимодействия, который позволяет им быть заменяемыми or изменяемыми, без нарушения integrity системы):
   • Определение ресурса (означает, что каждый ресурс должны быть обозначен постоянным идентефикатором)
   • Управление ресурсами через представление (означает, что клиент хранит ресурс в виде его представления, и при желании изменения ресурса он отправляет serverу информацию о том, в Howом виде он хотел бы видеть этот ресурс; server же рассматривает этот How request How предложение, и сам решает, что делать ему с хранимым ресурсом)
   • Самодостаточные messages (каждое сообщение содержит достаточно информации, чтобы понять, How его обрабатывать)
   • Гипермедиа (означает, что клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на server)
   • Система слоёв (означает, что в системе может быть больше двух слоёв (клиент и server), и при этом каждый такой слой знает только о своих соседних слоях, и не знает об остальных слоях, и взаимодействует только с соседними слоями)
   • Код по требованию (означает, что функциональность клиента может быть расширения за счёт загрузки codeа с serverа в виде апплетов or сценариев)

   Удовлетворение этим требованиям позволяет добиться следующего:

   • Надёжность
   • Производительность
   • Масштабируемость
   • Прозрачность взаимодействия
   • Простота интерфейсов
   • Портативность компонентов
   • Лёгкость внесения изменений
   • Способность эволюционировать, приспосабливаясь к новым требованиям

Для этого существует удобный класс SimpleDateFormat. Экземпляру этого класс можно передать шаблон представления даты, и тогда он в таком виде будет возвращать date (в формате строки String), либо считывать date (из строки String). Выглядит это всё следующим образом:

Date date = new Date(); // получаем текущую date
SimpleDateFormat formatter = new SimpleDateFormat("d-MM-yy HH:mm:ss"); //создаём экземпляр класса SimpleDateFormat
         								//и передаём ему шаблон представления даты и времени
String dateAsString = formatter.format(date); //преобразуем date в строку заданного формата

Date dateAfterConversion = formatter.parse(dateAsString); //преобразуем строку обратно в date

URI расшифровывается How Uniform Resource Identifier и переводится How "унифицированный идентификатор ресурса". URI — это последовательность символов, идентифицирующая абстрактный or физический ресурс. URL расшифровывается How Uniform Resource Locator. То есть это некий унифицированный указатель на ресурс, однозначно определяющий его месторасположение. URL служит стандартизированным способом записи address ресурса в сети Интернет.
Их отличия в том, что URI — это некоторый идентификатор ресурса, который позволяет этот ресурс How-то идентифицировать, а URL — это указатель на ресурс, он даёт информацию о том, где находится ресурс. Таким образом URL — это URI, который помимо идентификации ресурса, даёт информацию о его местонахождении.

Сокеты — это связка IP-address + порт, позволяющая из внешней сети однозначно идентифицировать программу на компьютере or serverе. В Java для работы с сокетами есть два класса Socket и ServerSocket. Экземпляры первого класса играют роль клиента, экземпляры второго — роль serverа. Клиент может отправлять и принимать messages через сокет. Сервер же постоянно отслеживает requestы пользователей и отвечает на них.
Для того, чтобы отправить данные через сокет, в классе Socket существует класс getOutnputStream(), возвращающий исходящий поток, с которым уже можно работать How обычно. Для приёма информацию нужно воспользоваться методом getInputStream(), который возвращает входящий поток. Дальше с этим потоком можно работать How с обычно потом ввода. Также стоит отметить, что при создании клиентского сокета (экземпляра класса Socket) в конструктор нужно передать ip-address serverа и порт, на котором он работает принимающая программа-server.
При создании serverного сокета (экземпляра класса ServerSocket) нужно указывать только порт, через который будет работать программа. После этого вызывается метод accept(). Этот метод ожидание подключение клиента, а после этого возвращает экземпляр класса Socket, необходимый для взаимодействия с этим клиентом. Дальше работать идёт с экземпляром класса Socket, How в первом случае (в случае клиента).