Ответы пользователя по тегу RESTful API
  • Ответ в REST API?

    HAL, Siren, JSON-LD (последний похардкорнее, не факт что вам подойдёт).
    Ответ написан
  • Что использовать для проектирования и разработки REST API?

    https://github.com/swagger-api/swagger-codegen


    Server stubs: C# (ASP.NET Core, NancyFx), Erlang, Go, Haskell, Java (MSF4J, Spring, Undertow, JAX-RS: CDI, CXF, Inflector, RestEasy), PHP (Lumen, Slim, Silex, Zend Expressive), Python (Flask), NodeJS, Ruby (Sinatra, Rails5), Scala (Finch, Scalatra)


    Сами мечтаем интегрировать генерацию роутинга и DTO-шек по swagger-спецификации прямо в билд-процесс, но пока ещё не можем таким похвастаться)
    Ответ написан
  • Как кратко назвать RESTful API, которое, оказывается, никакое и не RESTful, ибо возвращает JSON/XML, кодов HTTP-ошибок не использует, да и URLы не те?

    вижу какие-то статьи, где пишут, будто если с JSON, то это вообще не REST API!

    если REST API - это когда без JSON и XML (т.е. на HTML), то какое же оно тогда API?!

    Ссылки на статьи пожалуйста. Там либо автор фантазирует, либо его неправильно понимают. Единственная причина, по которой автор мог так заявить, это то, что большинство современных RESTful API не гипермедийные. Но это не значит, что не стоит в принципе использовать тот же JSON, это лишь значит, что нужно стремиться включить в него гипермедийные возможности (см. JSON-LD, HAL, Siren) и сам API также строить на этой идее, которая заключается в том, что у вас есть одна "точка входа", а на все остальные ресурсы, имеющиеся в API, вы попадаете, переходя по ссылкам внутри других возвращаемых ресурсов, точно также как вы заходите на сайт, зная его доменное имя, и дальше ходите по ссылкам.

    Однако на практике пока этим пользоваться никто не умеет, гипермедийных апи сейчас единицы. Большинство апишек подразумевает чтение документации с жестко заданными URL ресурсов, по которым нужно обращаться. Ссылки же одних ресурсов на другие используются редко.

    не использующее (или почти не использующее) HTTP-кодов ошибок

    А вот ошибками все-таки стоит пользоваться.

    какие-то паттерны URL наподобие /images/ и /images/1, про какие-то PUT и DELETE, про коды ошибок...

    RESTful API и MVC — что это?
    Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.

    Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).

    Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.

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


    Видел слово "JSON-pure API"

    Это уже вкусовщина. Люди не любят XML в API за то, что его модель подходит для описания иерархических данных и документов, но не для привычных объектно-ориентированных отношений между сущностями (он-то и создавался для представления документов, а не для веб-сервисов). Поэтому популярность JSON растет до упора. Многие старые API до сих используют XML, и JSON-pure - способ похвалиться, что ваше API полностью JSON. Сама идея RESTful ничего не говорит о форматах ответа, за исключением того, что формату желательно быть гипермедийным.
    Ответ написан
  • RESTful API и MVC — что это?

    Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
    Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
    Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
    Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
    Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

    Есть и другие подходы к архитектуре распределенных приложений, например архитектуры, основанные на RPC (удаленный вызов процедур). Информация в таких архитектурах также представлена в виде некоторого набора сущностей, однако операции над ними определяются конкретной задачей, и для каждой сущности будет свой набор. Это больше соотвествует классическому ООП-подходу. Таким образом, RESTful следует подходу много сущностей (ресурсов) - мало операций (и эти операции известны заранее), а RPC - немного сущностей, но много операций над ними.

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

    Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

    Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

    Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.
    Ответ написан
  • Где проектировать Restful API?

    RAML (самый молодой, но рекомендую)
    Swagger
    Apiary

    Это фреймоворки для проектировния API. По сути предоставляют свой DSL для описания и ДОКУМЕНТИРОВАНИЯ (!) API. К большинству из них идут инструменты по генерации читабельных доков и всякие mock-инструменты и генераторы клиентов-загрушек и сервисов-заглушек (для тестирования сервисов и клиентов соответственно). Вот например тулзы для Сваггера: swagger.io/swagger-codegen :
    The Swagger codegen project allows generation of both client libraries and server stubs from a Swagger definition.


    vREST - более комплексный продукт, включающий автоматизацию тестирования, есть платные возможности.
    Mashape - большой продукт для предоставления API, используется многими крупными компаниями (напр., Близзы его юзают).

    P.S. Есть еще различные модели гипермедийных API (JSON-LD, HAL, Siren, и т.д.), но это пока не очень популярные вещи, поэтому если не готовы быть одним из первопроходцев, лучше попробуйте их потом, когда наберут популярность (если наберут).
    Ответ написан
  • Какой фреймворк на c/c++ выбрать для реализации REST API?

    Nipheris
    @Nipheris Куратор тега C++
    Попробуйте C++ Network Library (на гитхабе) - проект достаточно молодой, но имеет очень интересный функционал и массу удобных абстракций, есть реализации URI, HTTP-клиента и сервера. Фактически это обертка над boost.asio, позволяющая не писать веб-сервер и клиент с нуля. Требует С++11.

    Кроме того, если есть требования по надежности/нагрузке, то лучше иметь дело с проверенным веб-сервером, и тогда стоит посмотреть в сторону FastCGI - тогда в инет будет смотреть какой-нибудь nginx или апач, а ваше приложение будет получать по FastCGI запросы от веб-сервера. Библиотеки для С++ имеются.
    Ответ написан