Please enable JavaScript.

Coggle requires JavaScript to display documents.

GO (code review : (Imports (избегать переименования импортов (исключение -…

- - - - сокращения - все заглавными
        IDProcessor.
      - чем меньше скоуп, тем короче имя
      - MixedCase, не names_with_underscores
    - - Локальные
        переменные
        
        i to index
        
        Prefer r to reader
        
        Prefer b to buffer
      - параметры
        
        если тип говорящий - название короткое
        func AfterFunc(d Duration, f func()) *Timer
        
        если тип простой - название посложнее
        func Unix(sec, nsec int64) Time
      - Возвращаемые
        значения
        
        Понятные для понимания
      - receiver
        
        как можно короче
        т.к. часто встречаются в тексте
    - - Экспортные
        переменные
        пакета
        
        не повторяют имя пакета
        strings.Reader, не strings.StringReader
      - Интерфейсы
        
        с одним методом заканчиваются на er
      - Ошибки
        
        ошибки поведения (?) называются FooError
        type ExitError struct
        
        ошибки значения - ErrorFoo
        var ErrFormat = errors.New("image: unknown format")
      - Пакеты
        
        Избегать общих имен
        utils, common etc
        
        имя папки совпадает с именем пакета
        
        не использовать _
  - - - Изначальная проблема/задача
      - как была решена
      - почему было сделано так, а не иначе
      - на что обратить внимание при чтении/ревью кода
      - ограничения кода
    - - есть ли доступ у всех ко внешним ссылкам
      - не стоит включать информацию, релевантную для ветки, но не для мастера
- - - - Разное
        
        Pеализация поддержки HEAD запросов веб-сервером обязательна.
        
        Кодировка только UTF-8
        Accept: application/json, /; q=0.01
      - методы
        
        GET /:entity/:id — getById
        
        В случае успеха сервер возвращает 200 OK с полями объекта в формате JSON в теле ответа (без дополнительного оборачивания в какой-либо объект)
        
        В случае, если объект с такими id не существует, сервер возвращает 404 Not Found
        
        В ответе обязательно должны быть заголовки, касающиеся политики кэширования, т.к. браузеры активно кешируют GET и HEAD запросы. При остутствии какой-либо политики управления кэшем должно быть:
        
        GET /:entity[?param1=...&param2=...] — списочный get
        
        Простой случай: в случае успеха сервер возвращает 200 OK с массивом объектов в формате JSON в теле ответа (т.е. ответ начинается с [ и заканчивается ]).
        
        Если массив получился пустой, всё равно вовзращается 200 OK с пустым масивом [] в теле ответа.
        
        Более сложный вариант: возвращается объект, в одном из полей которого — искомый массив. В остальных полях — данные о пагинации, фильтры, счётчики и пр. Только держите это консистентным по всем api.
        
        HEAD /:entity[/:id] — запрос заголовков
        
        Полный аналог GET с таким же URI, но не возвращает тело ответа, а только HTTP-заголовки.
        
        Реализация поддержки HEAD запросов веб-сервером обязательна.
        
        Активно используется браузерами в качестве автоматических pre-flight запросов перед выполнением потенциально опасных, по их мнению, операций. Например, браузер Chrome активно кидается head-запросами для получения политик CORS при кросс-доменных операциях (виджеты и пр). При этом ошибка обработки такого head-запроса приведёт к тому, что основной запрос вообще не будет выполнен браузером.
        
        Может использоваться для проверки существования объекта без его передачи (например, для больших объектов типа мультимедиа-файлов).
        
        POST /:entity — создаёт новый объект типа :entity
        
        Возвращать тело ответа чаще всего не требуется, так как у клиента есть все необходимые данные, а id созданного объекта он может получить из Location.
        
        Также метод POST используется для удалённого вызова процедур (RPC), в этом случае ответ будет иметь статус 200 OK и результаты в теле. Вообще смешивать REST и RPC в одном api — идея сомнительная, но всякое бывает.
        
        Единственный неидемпотентный некешируемый метод, т.е. повтор двух одинаковых POST запросов создаст два одинаковых объекта.
        
        В теле запроса должны быть перечислены поля объекта в формате JSON без дополнительного заворачивания, т.е. {"field1":"value","field2":10}
        
        В случае успеха сервер должен возвращать 201 Created с пустым телом, но с дополнительным заголовком
        Location: /:entity/:new_id
        указывающим на месторасположение созданного объекта
        
        PUT /:entity/:id — изменяет объект целиком
        
        PATCH /:entity/:id — изменяет отдельные поля объекта
        
        DELETE /:entity/:id — удаляет объект, если он существует.
        
        OPTIONS /:entity[/:id] Получает список методов, доступных по данному UR
    - - Client-Server
      - Stateless
      - Cacheable
        
        ответы сервера должны помечаться как кэшируемые или некэшируемые.
      - Uniform interface
        
        определение ресурсов
        
        В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе и т.д. Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.
        
        управление ресурсами через представления
        
        В REST у сервера полный контроль над ресурсами, и он отвечает за любые изменения. Когда клиент хочет внести изменения в ресурсы, он посылает серверу представление того, каким он видит итоговый ресурс. Сервер принимает запрос как предложение, но за ним всё так же остаётся полный контроль.
        
        самодостаточные сообщения
        
        самодостаточное сообщение содержит всю информацию, которая необходима для понимания его получателем
        
        ограничение гипермедиа
        
        В REST серверы должны посылать клиентам только гипермедиа.
      - Layered system
      - Code on demand
    - - POST -- create
      - GET -- read
      - PUT -- update/replace
      - DELETE -- delete
      - PATCH -- partial update/modify