레벨 40. 레벨 주제에 대한 인터뷰 질문에 대한 답변

IP 주소는 TCP/IP 프로토콜 스택을 기반으로 구축된 컴퓨터 네트워크에 있는 노드의 고유한 네트워크 주소입니다. 인터넷에는 전 세계적으로 고유한 주소가 필요합니다. 로컬 네트워크에서 작업하는 경우 네트워크 내 주소의 고유성이 필요합니다. IPv4 프로토콜 버전에서는 IP 주소의 길이가 4바이트이고, IPv6 프로토콜 버전에서는 IP 주소의 길이가 16바이트입니다. 일반적으로 IPv4 프로토콜 버전의 IP 주소는 점으로 구분된 0에서 255 사이의 값을 갖는 4개의 십진수로 작성됩니다(예: 192.168.0.3).

도메인은 도메인 이름 시스템의 다른 이름과 달리 자체 이름을 갖는 웹사이트 주소 또는 특정 영역입니다. 도메인은 첫 번째 수준, 두 번째 수준, 세 번째 수준 등이 될 수 있습니다. 일반적으로 1차 도메인은 일반 사용자가 등록할 수 없습니다(1차 도메인의 예로는 ".ru", ".com", ".net" 등). 일반적으로 세 번째 및 후속 수준의 도메인을 하위 도메인이라고 합니다.
호스트 는 로컬 또는 글로벌 네트워크에 연결된 특정 컴퓨터 또는 서버입니다. 호스트는 TCP/IP 서비스 환경에서 고유한 주소(IP 주소)를 가지고 있습니다.

GET, POST, PUT, DELETE, 옵션, HEAD, 패치, 추적, 링크, 링크 해제, 연결.

GET 메소드는 지정된 자원의 컨텐츠를 요청하는 데 사용됩니다. POST 메서드 는 사용자 데이터를 지정된 리소스로 전송하는 데 사용됩니다. HEAD 메소드는 일반적으로 메타데이터를 검색하고, 리소스 존재 여부를 확인하고(URL 유효성 검사), 마지막으로 액세스한 이후 변경되었는지 확인하는 데 사용됩니다. HEAD 메소드는 서버 응답에 본문이 없다는 점을 제외하면 GET 메소드와 유사합니다. GET 메소드는 전체 요청을 의미하지 않고 URL만 의미하기 때문에 POST의 단순화된 버전으로 간주됩니다.

REST 는 분산 애플리케이션 구성 요소가 네트워크를 통해 상호 작용하는 방식에 대한 아키텍처 스타일입니다. 이 용어는 2000년 로이 필딩(Roy Fielding)에 의해 만들어졌습니다. 그는 또한 분산 애플리케이션이 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 в первом случае (в случае клиента).