Я видел пару фреймворков и учебных пособий, которые рекомендуют тип MIME, специфичный для поставщика, чтобы «решить» проблемы с превращением вашего REST-интерфейса в «действительно RESTful» просто потому, что это можно сделать и каким-то образом это делает его кошерным для службы REST.
Одна из проблем этого подхода заключается в том, что по своей природе это хак или мошенничество, чтобы «заставить его работать» так, как вы хотите, когда весь смысл перехода на REST-сервис, управляемый гипермедиа, заключается в изменении моделиваш API и сервис и измените подход к проблеме.Пролить «действительное» или разрешенное, но не рекомендуемое значение HTTP для Content-Type - все равно что сказать голодающим венесуэльцам, что крысы - рыба, чтобы они могли есть их без греха во время Великого поста.Что-то не так с едой крысы, если это все, что у тебя есть?Возможно нет.Но притворяется, что это рыба, делает ее рыбой?Конечно, нет.Если вам нужен интерфейс, управляемый контрактом, используйте RPC или SOAP или даже пользовательский тип MIME.Но не указывайте на спецификацию и говорите, что это Отдых, потому что в конце концов вы едите крысу, и все это знают, а вы лжете только себе.
Вторая проблема заключается в том, что вы теряете действительноеНаграды за интерфейс, управляемый гипермедиа, когда вы сокращаете углы.Сразу же вы столкнулись с проблемами с пользовательскими агентами и вашим собственным сервером, вынужденным перепрыгивать через обручи или просто сдаваться, потому что mime-тип был незнаком.И все потому, что вы думали, что могли бы иметь и то и другое, когда смысл не в том, чтобы произвести впечатление на ваших клиентов претензиями на настоящую услугу Отдыха или немного облегчить нагрузку, сбросив (очевидно, ценный для некоторых контекстов) дополнительный вес контракта.управляемое взаимодействие, оно должно было изменить то, как ваш сервис на самом деле взаимодействовал с внешними клиентами.
Наконец, мне действительно непонятно, как конкретный тип MIME вендора обеспечивает выполнение контракта лучше, чем определенная конечная точка?Все сайты, которые упоминают эту технику, кажутся просто светящимися от облегчения, что эта опция существует, и, откровенно говоря, немного самодовольны и довольны тем, что используют ее, как будто они знают, что это технически "непослушно", но это так просто и исправляетвсе.Что это исправит?В вашем случае, почему бы вам просто не получить входящий person запрос / контент по адресу:
POST /myRestService/people
, и если у них есть какой-то другой запрос, отправьте его на другую конечную точку, предназначенную для этого другоготип данных?Если вам нужен метод does_something, вы бы не пошли с:
GET /myRestService/people/personID_123/does_something
или
GET /myRestService/people/does_something/personID_123
в зависимости от точного контекста?
И простотак что я не звучу злобно на вершине психов, любое разочарование или гнев вовсе не направлены на вас или ваш вопрос, но на «решение» продавца типа «пантомима» и навязчивой идеи у каждого разработан для «Roy Fielding, официально одобренного и помеченного как действительный REST-сервис», который, очевидно, никто даже не может предоставить работающему публичному примеру, оставляя только ощущение безотлагательности, чтобы принять его немедленно, используя любые необходимые ярлыки, и мы можемс позором и пальцем, указывающим позже, когда мы на самом деле исправляем проблемы, возникшие из-за ярлыков.