REST API - должен ли сервер предоставлять уже обработанные данные или клиент обрабатывает их сам

Question

Я бы хотел задать один простой вопрос о REST-подходе.

Итак, вот проблема: Мы должны отображать текущую дату на стороне клиента в этой форме: ДД.ММ.ГГГГ ЧЧ: ММ: СС

Теперь вопрос: должен ли сервер предоставить клиенту готовую к отображению строку, содержащую, например: «04.07.2018 13:53:23» ИЛИ ЖЕ должен ли сервер предоставить клиенту какую-то общую строку «Дата», например: 2018-07-02T09: 22: 02 + 02: 00 и клиент должен обработать его так, как он должен отображаться (формат ДД.ММ.ГГГГ ЧЧ: ММ: СС).

Буду благодарен за ответы, которые ответят, какой подход лучше в этой ситуации (в отношении REST архитектурного дизайна).

Answer 1

Для меня обмен датами в ISO 8601 имеет гораздо больше смысла. Это хорошо известный и широко используемый формат, который может быть проанализирован большинством инструментов манипулирования датами. Если вы получаете дату в формате ISO, у вас гораздо больше гибкости на стороне клиента. Вы можете отформатировать его так, как хотите, без изменения кода сервера и использовать разные форматы в разных местах.

Answer 2

Оба аспекта имеют свои плюсы и минусы

Готов к отображению строки

Плюсы

• Меньше обработки на стороне клиента (дата и время уже отформатированы)

Против

• Меньше гибкости на стороне клиента для отображения даты и времени в нескольких форматах
• Высокая обработка на сервере (централизованная обработка)

Общий формат (например, метка времени Unix)

Плюсы

• Больше гибкости на стороне клиента (многократное использование для отображения требуемого формата времени)
• Меньше серверной обработки (децентрализованный процесс форматирования даты / времени)

Против

• Больше обработки на стороне клиента (немного кода для отображения даты / времени, также может потребоваться внешняя библиотека для форматирования)

В качестве предложения

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

Если вы ожидаете, что средняя клиентская база и клиентское приложение не будут слишком сложными для повторного использования / переформатирования времени на нескольких экранах, тогда «Готово к отображению» будет хорошо.

Answer 3

Вы должны использовать пользовательские конвертеры для ex: MessageBodyWriter в Джерси

код:

package com.arun.java.customconverter;

import java.io.IOException;
import java.io.OutputStream;
import java.lang.annotation.Annotation;
import java.lang.reflect.Type;
import java.util.Date;

import javax.ws.rs.Produces;
import javax.ws.rs.WebApplicationException;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.MultivaluedMap;
import javax.ws.rs.ext.MessageBodyWriter;
import javax.ws.rs.ext.Provider;

@Provider
@Produces("text/shortdate")
public class ShortDateMessageBodyWriter implements MessageBodyWriter<Date> {

    @Override
    public boolean isWriteable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType) {
        // TODO Auto-generated method stub
        return Date.class.isAssignableFrom(type);
    }

    @Override
    public void writeTo(Date t, Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType,
            MultivaluedMap<String, Object> httpHeaders, OutputStream entityStream)
            throws IOException, WebApplicationException {
        String shortdate= t.getDate()+"-"+t.getMonth()+"-"+t.getYear();
        entityStream.write(shortdate.getBytes()); 

    }

}