Я на этой невместимости сейчас весь проект сделал

А кто дружил Swagger и JSON API?

ну-ка расскажи. а то вот как-то все идеально у меня более того, я использую https://github.com/swagger-api/swagger-node чтобы вывернуть цикл разработки и иметь единственную точку для документации, схем валидации, моков

Так

JSON API = http://jsonapi.org, а не API в формате JSON

и посыпать сверху генерированными тестами: https://github.com/earldouglas/swagger-test

JSON API = http://jsonapi.org, а не API в формате JSON

а. хм.. момент..

Ну понятно в чём несовместимость

Ну понятно в чём несовместимость

без "www." 😂

Ну понятно в чём несовместимость

Да, чё-то у них с конфигом) Обновил ссылку

Вижу. Их я не дружил, не помогу :(

JSON API = http://jsonapi.org, а не API в формате JSON

пока не вижу никаких проблем. ведь в основе swagger лежит просто json-schema что тебя смущает?

С тем, что модель данных разная

jsonapi.org ~= GraphQL

swagger позволяет сделать любую схему jsonapi предлагает определенную схему разве не так? в чем тут несовместимость?

а, в формате входных данных, что ли?

Ну у них принципиально разный подход

jsonapi.org ~= GraphQL

мноооооого костылей

Не

У них оч похоже

Ну у них принципиально разный подход

но в чем? ))) я вижу что можно возвращать дополнительные данные. отлично, в swagger это можно описать!

> JSON API легко покрывает все CRUD-кейсы, включая пагинацию, фильтрацию, оптимизацию трафика ("includes") и типизацию. На текущий момент, он выглядит как полноценная альтернатива GraphQL и вполне возможно взаимозменяем.

но в чем? ))) я вижу что можно возвращать дополнительные данные. отлично, в swagger это можно описать!

Тип объекта задаётся в самом объекте

https://medium.com/@knightstickc/building-an-api-with-swagger-json-api-and-rails-part-1-dbcd5bd3bd23

Вот чё-то по теме

ну и что? :) просто еще одно поле данных, которое можно описать в json-schema, а значит и в swagger

От поля "type" зависит формат данных в "attributes"

{ "data": [{ "type": "articles", "id": "1", "attributes": { "title": "JSON API paints my bikeshed!" }, "links": { "self": "http://example.com/articles/1" }, "relationships": { "author": { "links": { "self": "http://example.com/articles/1/relationships/author", "related": "http://example.com/articles/1/author" }, "data": { "type": "people", "id": "9" } }, "comments": { "links": { "self": "http://example.com/articles/1/relationships/comments", "related": "http://example.com/articles/1/comments" }, "data": [ { "type": "comments", "id": "5" }, { "type": "comments", "id": "12" } ] } } }] }

Также может быть: { "type": "people", "id": "9", "attributes": { "first-name": "Dan", "last-name": "Gebhardt", "twitter": "dgeb" }, "links": { "self": "http://example.com/people/9" } }

В итоге вся валидация строится на "type"

либо я недостаточно знаком с json api, либо тут можно иначе взглянуть на зависимости: от адреса, по которому делается запрос — зависит тип возвращаемых данных от типа данных — зависит то, какие могут быть дочерние элементы, и какие у них типы данных то есть, все заранее известно, статически, еще до рантайма

дочерние объекты ведь появляются не с неба, а на основе полей связи? значит можно описать, что у объекта типа "articles" в поле "relationships" могут быть ссылки только на "author" и "comments" друге дело, что swagger (json-schema) не имеют механизмов направленых на облегчение именно этой работы. но выносить и переиспользовать описания можно

В итоге кажется Swagger это совсем про другой вид API

я не знаю как в других форматах, но я для себя не вижу проблем в этой задаче кстати, спасибо за jsonapi, видимо буду его использовать, выглядит удобно! :D

но вообще, я читал где-то что над спекой swagger работают, чтобы можно было проще описывать ссылки на другие объекты

Вообще у JSON API ноги отсюда растут - http://ember-jsonapi-resources.com/

так, есть ограничение. нельзя описать поле "included" более подробно, чем просто "массив объектов с полями type, id, attributes, links", поскольку swagger не позволяет использовать oneOf/anyOf

Плюс эти oneOf/anyOf будут не совсем то

По сути Swagger = JSON Schema

Со всеми её статичными и примитивными возможностями

то есть, нельзя описать, что "included" должно содержать oneOf types/people, types/comment

Вот так только можно описать похоже - https://medium.com/@knightstickc/building-an-api-with-swagger-json-api-and-rails-part-2-8f9691e3de04

У вас тут списочка литературы нет?

по чему?

Вот так только можно описать похоже - https://medium.com/@knightstickc/building-an-api-with-swagger-json-api-and-rails-part-2-8f9691e3de04

мужик тут верно говорит: http://discuss.jsonapi.org/t/using-swagger-with-jsonapi-definitions/400/5

Он говорит I would love to see full convergence of openapi, json schema, and jsonapi, with a good example!

Потому что I gave up on jsonapi with swagger/openapi.

А вот следующий чел говорит по делу: JsonApi and hypermedia as a whole are orthogonal to OAS/Swagger fundamentally. It is very simple, the foundational element of the OAS specification is the path, and while in hypermedia APIs it is the vocabulary of the hypermedia. Some elements could be incorporated, but there is no way to fundamentally map one to another without changes to either of those basic properties.

короче, поле ответа "data" можно детально описать уже сейчас (и это кажется самое главное в ответе) а поле "included" можно описать на сегодняшний день поверхностно (и ладно)

Ну у них принципиально разный подход

Собственно вот

да я эту гипермедию на сваггере писал! 😂 я к тому, что может я чего-то не понимаю, но для меня гипермедиа — данные, сваггер/схема — формат описания данных, и все это выглядит предельно просто. и пусть даже не все можно описать в сваггере до уровня конкретного поля из-за динамической природы гипермедиа, это все равное дает уйму преимуществ. но если надо детально описывать динамические поля уже сегодня — может отличные от сваггера форматы дают такую возможность. тут все от целей зависит. обычно же good enough is enough :)

))

https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/

Надо подумать: + Отказаться от hypermedia в JSON API и прийти к Swagger, где type == URI + Отказаться от Swagger и прийти к hypermedia с отдельной схемой, как GraphQL Принять во внимание: + Тесты + Security + авто-генерация кода вместо ORM

прими еще во внимание что дают инструменты вокруг swagger: - автогенерация тестов - валидации входящих/исходящих данных - автогенерация mock ответов (чтобы клиент разрабатывался до окончания работы над сервером)

а это как?

"где type == URI" — вот почему я не видел проблемы. я был уверен, что не может возникнуть желания отдавать разные типы по одному и тому же URI

а это как?

https://github.com/earldouglas/swagger-test https://github.com/swagger-api/swagger-node мне очень нравится swagger-центричная разработка

даже роуты не надо описывать в коде — достаточно указать в swagger имя контроллера, который должен обрабатывать запрос

надо будет для мобилок через swagger сделать API

так и делал для одного клиента

Ребята, есть хорошие доки по node + mongoDB? Спасибо

Есть, незачто )

(https://github.com/sahat/hackathon-starter)

Привет, такой вопрос, если при обработке запроса от 1го клиента, возникает ошибка, процесс упадет и все клиенты обрабатываемые этим процессом в д анный момент отвалятся, как с этим быть? Напрмер в пхп где на 1го клиента новый процесс, клиенты изолированы и такой проблемы нет

писать правильный код, обкладыватся try catch

Я так и представлял себе это, но после ПХП как то страшно становится

ну пхп поэтому и медленее )

Набирать обработчик исключений)

Написать *

что это значит? что то вроде global.on('error') ?

process*

Да process. On

по моему наверху перехватывать не хорошо

+, а что делать)

Писать их в лог + оповещать

ну ладно я вас понял, спасибо

а шарить данные между процессами? мемкеш ?

Тут не подскажу (

какой сейчас топовый интсрументарий для разработки серьезных вещей на ноде?)