Экономия в качестве замены общедоступного API для REST?

Я начал создавать API для нового сайта, над которым работаю.

Изначально я хотел сделать его обычным REST API, но продолжаю думать о том, насколько крутой была бы бережливость с возможностью компилировать несколько клиентских библиотек в один пакет.

Является ли Thrift жизнеспособным вариантом для общедоступного API, сокетов и всего остального, или мне следует придерживаться REST?

И если REST, что будет лучшим подходом для создания нескольких клиентских библиотек, или мне просто придется разобраться и написать их?

В противном случае, если бы Thrift, мог бы я скомпилировать библиотеки и просто предложить ссылки для скачивания или просто дать разработчикам файл .thrift для создания их собственной библиотеки?

Примечание. Это все еще небольшой сайт, поэтому я бы создал файл спецификации экономичности только для API.


api rest thrift
person Johann du Toit    schedule 06.04.2012    source источник
comment
Это зависит от того, кто подключится и как? (Лично я считаю, что ProtocolBuffers лучше и лучше спроектирован, даже если нет стандартного сервера RPC. Для более сложных RPC есть такие вещи, как ICE, но, опять же, who подключится и как?)   -  person    schedule 06.04.2012
comment
Таким образом, в Google Buffers я мог бы по-прежнему определять типы объектов, сериализовать и отправлять по http. Очень похоже на замену JSON, но с определенным типом, которого ожидает клиент? У вас есть опыт работы с этим в PHP?   -  person Johann du Toit    schedule 06.04.2012
comment
Protocol Buffers - это протокол двоичной сериализации, очень похожий на Thrift. (Thrift - это просто комплексный пакет, поскольку он также включает реализации конечных точек службы.) В ProtocolBuffers есть поддержка конечных точек RPC, например Поддержка RPC была разработана в, но стандартная реализация сервера отсутствует. Однако есть проекты, которые обеспечивают соответствующие конечные точки RPC.   -  person    schedule 06.04.2012
comment
Если вы решите использовать REST-подобные API: и хотите создать заглушку, попробуйте swagger, и если вам нужен общий клиент ознакомится с HAL и API-интерфейсами Hypermedia в целом.   -  person mb21    schedule 24.09.2014

Ответы (4)


arrow_upward
12
arrow_downward

Во-первых, REST и Thrift - это от яблока к апельсину: первый - это общий стиль, второй - специфическая бинарная система RPC.

Но для общедоступных интерфейсов я думаю, что REST с использованием стандартных текстовых форматов (обычно JSON или XML) имеет больше смысла; поскольку к нему проще получить доступ с любого языка или платформы; и хотя на многих платформах есть клиенты Thrift, это еще большая работа. Он также навязывает клиентам определенный стиль доступа, в значительной степени используя определенную клиентскую библиотеку Thrift.

Так что вопрос, скорее, будет заключаться в том, что именно вы пытаетесь получить? Что именно вы считаете там "крутым"? Если вы просто хотите поиграть с новой технологией, в этом нет ничего плохого, но вам следует сначала поиграть с ней, а затем посмотреть, имеет ли это смысл.

person StaxMan    schedule 12.04.2012
comment
Просто смотрю на разные способы делать что-то. Создавал Rest API и библиотеку Java, начал задаваться вопросом, нельзя ли это сделать за меня? Но я согласен, что REST будет наиболее удобен для использования любым из клиентов, обращающихся к API. Но вся эта работа над библиотекой кажется проблемой. Что, если я добавлю еще один параметр к объекту в выводе API, тогда мне придется обновить все клиентские библиотеки для значения, и ошибки обязательно произойдут. Любой совет ? - person Johann du Toit; 12.04.2012
comment
То же самое и с Trhift, n'est pas? Вы должны изменить схему, все должны перекомпилировать ее для новых классов ... Однако в Java, REST, я использую POJO, которые можно использовать совместно. Пакеты связывания данных (Jackson для JSON, JAXB для XML) прекрасно справляются с сериализацией / десериализацией. А затем базовый HTTP-клиент (Apache или async-http-client); или еще лучше, Jersey-client может упростить доступ. - person StaxMan; 12.04.2012
comment
Имеет смысл спасибо. Закончил написанием обычного API для отдыха и созданием пользовательских библиотек. - person Johann du Toit; 13.04.2012

arrow_upward
10
arrow_downward

Если ваш API достаточно прост, чтобы вы могли выразить его с помощью REST и с приемлемой производительностью, то, вероятно, было бы лучше придерживаться REST, поскольку обычно существует более низкий барьер для написания клиентского кода для API на основе REST.

Если, с другой стороны, REST имеет сложность или проблемы с производительностью, используйте бережливость или что-то еще более подходящее.

person Davorin Ruševljan    schedule 06.04.2012

arrow_upward
0
arrow_downward

Вы окажетесь в одной лодке, если будете самостоятельно разрабатывать разные библиотеки. Я думаю, что людям будет проще использовать REST даже без библиотеки (или если они будут реализовывать свои собственные). С другой стороны, если вам нравится то, что Thrift является двоичным, json также можно использовать аналогичным образом, дополнительную информацию см. Здесь http://bsonspec.org/

person Igor Čordaš    schedule 26.05.2014

arrow_upward
0
arrow_downward

Одним из больших преимуществ REST является то, что вам не нужно создавать клиентские библиотеки. Вы можете просто указать разработчикам на свой список конечных точек, и они смогут понять это оттуда. Некоторые большие плохо спроектированные службы REST будут предоставлять клиентские библиотеки, чтобы замаскировать их уродство, но если API прост и хорошо спроектирован, в этом нет необходимости.

person miguel    schedule 04.11.2014