Mimetypes для УСПОКОИТЕЛЬНОГО API
Если Вам действительно не нужен Ваш Регистратор для помех, Вы могли использовать
final Logger logger = LoggerFactory.getLogger(getClass());
3 ответа
Или я должен просто обслуживать "application / json", как кажется, большинство API?
Я так не думаю.
Тип носителя - единственная точка связи между вашим веб-приложением RESTful и клиентами, которые его используют. Документация ваших типов мультимедиа - это документация вашего API. Типы мультимедиа - это договор между вашими клиентами и вашим приложением. Исключив конкретный тип носителя, вы удалите важный элемент, который делает REST работоспособным.
Sun зарегистрировала эти миметики в IANA.
Не удалось найти упоминания об этом здесь . AFAIK, нет необходимости фактически регистрировать свой настраиваемый тип носителя в IANA. Похоже, что соглашение использует нотацию перевернутого домена application / vnd.com.example.app.foo + json, что предотвращает конфликты пространств имен. Если и когда ваш тип мультимедиа станет стабильным и общедоступным, это может быть хорошей идеей, но нет никаких требований. Впрочем, в этом могу ошибаться.
Получите ли вы какое-либо значение, указав полный mimetype? Вы бы сделали что-нибудь с полным mimetype иначе, чем если бы mimetype был application / json?
Мои 2 цента - Если API не будет обнародован, то я не вижу причин для полного mimetype. Mimetype application / json должно быть более чем достаточно. Вы уже знаете, какой тип json возвращается в ответ. Если API в конечном итоге станет общедоступным, тогда беспокойтесь о полном mimetype ... или просто дайте людям понять это.
Я использую свои собственные типы мультимедиа vnd.mycompany.mymediatype + xml для многих своих представлений. На клиенте я отправляю соответствующий класс контроллера в зависимости от типа носителя возвращаемого представления. Это действительно позволяет серверу управлять поведением моего клиентского приложения в ответ на пользователя, следующего по ссылке.
Лично я считаю, что использование application / xml и application / json - один из худших вариантов, которые вы можете сделать, если надеетесь для поддержки клиентов REST. Единственное исключение из этого - когда клиент использует только загруженный код (например, Javascript) для интерпретации данных.