REST API - нужно мнение по архитектуре - PullRequest
Новая
       6

REST API - нужно мнение по архитектуре

2 голосов
/ 08 января 2011

Я разрабатываю REST API. Часть, над которой я сейчас работаю, включает в себя простое чтение объектов в виде данных JSON с сервера и их изменение.

Ресурс, который я собираюсь использовать для этого, выглядит следующим образом: / data / {имя таблицы} / {ключ строки}

Я бы хотел разрешить операции GET и PUT на этом ресурсе.

Вопрос, с которым я борюсь, заключается в том, что я хотел бы вернуть другие данные вместе с объектом JSON, такие как сообщения клиентов, количество времени, которое потребовалось для прохождения туда-обратно в базу данных и т. Д. Я хотел бы также хотел бы разрешить отправку аргументов запроса с полезной нагрузкой в ​​тех случаях, когда URL был бы слишком длинным, если бы они были там включены.

Таким образом, ресурсы будут работать так:

GET 

GET /data/{table name}/{row key}

Сервер возвращает: 

{
   data:{...JSON OBJECT GOES HERE ....},
   message:"customer messages go here",
   responseTime:'123ms',
   otherInfo:"Yada yada yada;
}

PUT 

PUT GET /data/{table name}/{row key}

Клиент отправляет в качестве полезной нагрузки: 

{
   data:{...JSON object goes here...},
   queryArguments:{...extra long query arguments go here...}
}

Боюсь, это может нарушить правила для правильных ресурсов RESTful GET и PUT, потому что то, что вы отправляете на сервер, не совсем то, что вы получаете обратно, так как другая информация включается в полезную нагрузку. Я бы предпочел, чтобы каждая операция не была POST лекарством.

Я слишком увлекаюсь этим? Есть ли какой-то другой способ, которым я должен структурировать это?

Спасибо!

Редактировать ::::

Следует отметить, что в ресурсе: /data/{table name}/{row key} я использовал «имя таблицы» и «ключ строки» для простоты. Это для использования с базой данных noSQL. Этот ресурс предназначен для работы аналогично Amazon S3. "uuid" на самом деле было бы лучшим описанием, чем "ключ строки".

Ответы [ 3 ]

3 голосов
/ 08 января 2011

Что касается меня, то все зависит от того, как будет использоваться дополнительная информация.Для моих клиентов responseTime - это не вопрос (или, по крайней мере, я так думаю :), им просто нужен этот ответ.Для меня как разработчика это может помочь в отладке.Поэтому, когда клиент дает мне медленный запрос, я могу легко его проверить, и эта дополнительная информация может помочь.Здесь я имею в виду, что можно создать простой URL, как вы указали / data / {имя таблицы} / {ключ строки} и отправить только ответ в соответствии с этим запросом, и вы можете создать еще один URL / data / {имя таблицы} /{ключ строки} / debug или что-то еще, чтобы получить те же данные с дополнительной информацией, такой как "reponseTime".Просто идея;)

ОБНОВЛЕНИЕ: Ах, да, забыл: не используйте имя таблицы как часть вашего URL, по крайней мере измените его имя.Я не люблю никому рассказывать, как называются мои таблицы, если кто-то собирается взломать мою БД, добавляя дополнительный код, я бы хотел, чтобы она больше времени искала какую-либо информацию вместо того, чтобы указывать свою информацию на табличке:)*

2 голосов
/ 11 января 2011

Я не вижу ничего плохого в вашем подходе.
Но если бы я реализовывал этот сценарий, я бы задал себе следующие вопросы:

  1. Кто мой ресурс?
  2. Является ли сообщение клиента частью ресурса?
  3. Является ли "время ответа" частью ресурса?

Давайте возьмем в качестве примера "время ответа".Если это часть вашего ресурса, ваш подход идеален, и больше ничего не нужно делать.
Однако, если он не является частью ресурса, верните его в качестве заголовка HTTP.Достаточно справедливо.

2 голосов
/ 08 января 2011

Я не вижу в этом ничего плохого, выглядит довольно стандартно для меня.Я не уверен, что вы планируете передать в queryArguments, это где вы бы указали обратный вызов для выполнения для клиентов JSON-P?Единственное, что я бы порекомендовал вам иметь в виду, это то, что REST имеет дело с ресурсами, и это не обязательно отображает 1-к-1 с таблицами.Вместо использования ключа строки вы можете захотеть использовать GUID или UUID определенного типа, которые вы можете сопоставить с этим ресурсом.

...