Комментарии 8
Изменения в протоколах API могут привести к совместимости проблемам,
Проблемам совместимости? Кажется, слова местами перепутаны
Чет все перепутано - протоколы, транспорты и форматы...
А что именно? Тут вопрос, как оперировать понятиями, т.к. в принципе от архитектурной концепции я не отходил.
вопрос в трактовках и первоисточниках на которых мы обучаемся, я в основном по статьям и книгам обучался не переведенным, поэтому мы можем немного по разному смотреть на некоторые формулировки. Буду рад, если подскажешь, что именно смутило. Я конечно не гигант в проектировании API)))), но пока все интеграции вроде как были успешными
А почему API социальных сетей вынесено отдельным пунктом? Чем отличается от web api?
В России очень хорошо развиты компании работающие в ФинТех, соответственно, когда мы говорим об API, то традиционно подразумеваем микросервисные API, а особенно протоколы REST и SOAP.
Откуда такой вывод вдруг?
Отсутствие строгой спецификации может привести к разнообразию реализаций и сложностям в согласованности интерфейсов.
REST API обладают унифицированным интерфейсом, что означает, что клиенты и серверы могут взаимодействовать между собой, следуя общим правилам, без необходимости знания подробностей реализации.
Так просто или сложно все таки? И почему вдруг REST делает необязательнымт знания о внутреннем устройстве? Кажется любой api (нормальный) как раз делает знания необязательными, т.к. предоставляет интерфейс
Сделайте мне бота, который будет по фамилии и городу предоставлять ник пользователей в телеграм
При этом метод называется search_relatives. Кажется в REST стиле было бы что то типа nicknames/search например. Непонятно при чем тут relatives вообще
видимо пока писал, немного перемудрил) но выводы берутся очень просто: в рф ит крайне хорошо развит в финтех (исследования форбс и рбк), а так как у меня знакомые в топ 5 банков и используют два основных протокола, также я собеседую и помогаю собеседовать аналитиков и в навыках у большинства кроме rest и soap не видел ничего.
по-второму комментарию, REST API не предоставляют формальной спецификации, как это делают, например, SOAP-сервисы с их WSDL-описанием. Это может привести к недостаточной документации и неоднозначности в толковании, как использовать API, ну как то так. Почему рест делает необязательным знания о внутреннем устройстве? Тут надо конечно понимать нюансы, но одним из его ключевых принципов является принцип унифицированного интерфейса в REST и этот принцип делает его более независимым от деталей внутренней реализации сервера и клиента. Вот почему он делает необязательным знание о внутреннем устройстве.
третий комментарий, необязательно,тут больше для информации приведен код и простоты восприятия.
Почему вы так решили?
Иногда говорят не протоколы, а архитектурные стили, но тут на любителя
REST это именно стиль для создания API - рекомендации. А SOAP уже полноценный протокол.
API от А до Я (теория и практика)