Согласованность API REST Twitter с размещением идентификатора

Question

Может ли кто-нибудь объяснить мне в терминах REST дизайнерское решение Twitter с размещением параметров в этих двух вызовах?Кажется, что: id размещение несовместимо и произвольно (хотя явно это было преднамеренно).

GET statuses/:id/retweeted_by
Show user objects of up to 100 members who retweeted the status.

GET statuses/retweets/:id
Returns up to 100 of the first retweets of a given tweet.

В их API есть и другие подобные примеры (https://dev.twitter.com/docs/api),, поэтому я определенно что-то упускаю.

Спасибо!

Answer 1

Я закончила с другом в Твиттере, который сказал:

"Я только что говорил с парнем, который первоначально написал эти два API конечные точки, и он не помнит почему. Чтобы ответить на ваш вопрос, хотя, вероятно, нет хорошей причины RESTful для такого дизайна. "

Answer 2

Просто гадать здесь

Кто-то в Твиттере однажды заметил, что API Twitter работает на нескольких сервлетах. Я могу только предположить, что это было связано - проще сопоставить /retweets/*, чем сопоставить каждую отдельную комбинацию.

Обновление : Я думаю, что история самого API также может быть актуальной. API Twitter не сильно изменился за последние годы, и если он действительно изменится, то это будет связано с добавлением новых функций. Конечная точка, такая как GET statuses/show/:id, является старой , а GET statuses/retweets/:id новее. Если бы Twitter в какой-то момент решил изменить соглашения об именах, он не мог бы просто переименовать старые, так как это сломало бы приложения.

Другая моя теория заключается в том, что GET statuses/retweets/:id на самом деле не относится к самому Твиту :id, а касается твитов, которые были основаны на нем. GET statuses/:id/retweeted_by напрямую связан с самим твитом, возвращая пользователей, а не другие статусы.

Меня тоже часто озадачивает последовательность имен. Я уверен, что у них есть свои причины.