Комментарии 27
Пишу вебапи на базе c#, вызываю из vue.js, возник вопрос: будут ли главы посвящённые языковой разнице в вызовах или вообще не планируется приводить код на каких-то конкретных ЯП, вызовы будут просто GET/POST запросами?
Идея книги интересная, поддерживаю в начинании!
github.com/twirl/The-API-Book#current-state-and-the-roadmap
Большинство примеров API в общих разделах будут даны в виде JSON-over-HTTP-эндпойтов. Это некоторая условность, которая помогает описать концепции, как нам кажется, максимально понятно. Вместо `GET /v1/orders` вполне может быть вызов метода `orders.get()`, локальный или удалённый; вместо JSON может быть любой другой формат данных. Смысл утверждений от этого не меняется.
Конечно, а с телефончика в метро как читать? Пдф это еще тот квест
Только что в ландшафт перевернуть.
На самом деле я порефакторил HTML-версию, она должна теперь нормально с мобильных читаться.
Единственный момент, который сбивает с толку своей простотой в подобных заметках, статьях, книгах с best-practices — это форма повествования «а давайте предположим, что ...». И поехали фантазировать. Из-за этого не очевиден поток мысли и как принимаются те или иные решения. А так же затрагивается очень тонкая тема оверинжениринга.
Когда большие блоки умозаключений строятся на предположении, что
существует принципиально два класса устройствхочется понять, когда же стоит остановиться в изучении доменной области и сказать «все, такого уровня абстракции нам пока хватит». Например, может же так получиться, что первые кофе-машины поддерживают и второй вариант АПИ тоже (т.е. автоматическое и ручное управление). И тут можно прийти к мысли: «делать рантайм для всех машин, т.к. апи то унифицировано».
Бизнес задачи очень разнообразны и лично я хотел увидеть процесс принятия решений при проектировании АПИ и пример-два с разбором такого «гайда». А в 9 главе получается наоборот, что мы разбираем пример и из него строится мысль, с некоторыми пометками «для общего случая» (например, есть какой-то свой статус очень важное замечание!)
Перечитал, и обратил внимание что в Приложении
POST /v1/orders {"coffee_machine_id", ....}
В этом запросе непонятно откуда берется "coffee_machine_id": в результатах поиска есть place и location, в тексте обсуждается что мы вводим дополнительные слои абстракции, чтобы пользователи нашего API в том числе не заботились деталями конкретной кофе-машины… и в результате coffee_machine_id из текущего API получить вроде бы неоткуда.
Подскажите, пожалуйста: это баг (не все детали расписаны) или фича (заложен сюжетный поворот для 2 части) или я где-то ошибся?
Книга: проектирование API