Олег Красавин: > Да, это стандарт. Почитайте официальный RFC на Oauth2
Во-первых, разве REST API обязательно предусматривает именно OAuth? Если тот же самый токен выдавать по логин-паролю юзера, без Applicationов и иже с ними, то это не REST API уже?
Во-вторых, может, я слепой, но я не вижу по вашей ссылке никаких упоминаний HTTP-заголовка "Authorization". Само слово "authorization" там встречается однократно, но почему нужно делать именно вот так (пример из Twitter):
POST /oauth2/token HTTP/1.1
Host: api.twitter.com
User-Agent: My Twitter App v1.0.23 Authorization: Basic eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJn
NmllS0dFS2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw==Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 29
Accept-Encoding: gzip
grant_type=client_credentials
Об этом я там ни слова не вижу.
> Простым switch()
Я не про обработку серваком, а про то, как послать этот Accept, если я в адресной строке браузера вбиваю такое: root/images.get?blabla=123456&token=uhygtfiyuijiphoyui
и хочу получить в окне браузера именно XML, тогда как по дефолту оно выдает JSON.
Вы, я вижу, вообще не понимаете, зачем какие-то запросы к REST API нужно делать из адресной строки :)
А ведь это реально удобно, а главное, очень просто - для 3rd-party новичков, которые будут с моим API работать.
> То есть результат запроса с любого устройства/места/планеты должен быть предсказуем.
Ну, если я пошлю те же самые куки, то он будет предсказуем.
Олег Красавин: > Потому что оно должно быть stateless
Почитал, что такое "stateless". Если правильно понял, то для этого на сервере не должно храниться никакой информации о сессии клиента.
Но как это вообще возможно? Ведь токен - это тоже инфа о сессии по сути. Если не хранить его на сервере, как тогда сервер будет проверять токен не expired ли и валидный ли вообще?
> без Authorization хедера не обойтись.
Почему именно хедером, почему не параметром GET-запроса?
Это какой-то негласный стандарт? Откуда ноги растут?
Или вы просто действуете по принципу "а что тут думать? раз есть фича - юзать надо!"
> а по поводу отдельных скриптов - www.slimframework.com как роутер для небольшого апи
Спс, глянем.
За идею с Accept спасибо, хотя есть у нее минусы.
Неужели вам никогда не приходилось с новым для вас REST API, если оно поддерживает GET (а не POST), экспериментировать прямо в адресной строке браузера?
Мне - да. ИМХО, это быстрейший и простейший способ разобраться с таким API - никаких снифферов, никаких написаний тестов на ЯП...
И вот именно поэтому я за access_token'ы, а не куки или Authorization; и поэтому же я против Accept. Короче, если хоть 1 метод API поддерживает GET-запросы, то я против любых заголовков.
Это - минус Accept'а. А плюсы есть? Если нет, то что же здесь "нормального"?
Ну и вернемся к теме вопроса.
Все-таки я хочу отдельные скрипты.
abcd0x00: а если у меня сразу все идет в дерево (скажем, DOM-дерево)?
Есть цикл, обходящий символы, в нем конечный автомат - switch, и вот в case'ах прямо сразу создаются объекты классов, таких, как HtmlDocument, HtmlElement, элементы запихиваются в коллекции childNodes и т.д.
Denis Zagayevskiy: ну, если вам нечего сказать, то как пожелаете. А если вам есть что сказать по подходу "без рекурсии", или хотя бы знаете, как такое называется общепринято, чтобы вбить в гугл и что-то найти, то зря удаляетесь, ИМХО.
Denis Zagayevskiy: что такое функциональное программирование, я знаю примерно.
Насчет основ - вы правы, но также параллельно им изучаю и готовые решения, в данном случае это Irony.NET (где, к слову, встретил и термин "AST"). То есть иду от примитивного к сложному, и параллельно от сложного к примитивному. Всегда так делал, и получалось, так я сети освоил, например. Что я делал не так?
Denis Zagayevskiy: похоже, рекурсии тоже не будет. Петр прав.
Будет другое: нарвавшись на "{" в value, мы создаем новый Object и далее ведем себя с ним так же, как и с коренным ("внешним") объектом, а при "}" закрываем этот объект и снова возвращаемся к "внешнему".
Так должно получиться без рекурсии.
Rsa97: спасибо и на том, конечно, прежде всего спасибо за "val3", но не понимаю, что вы хотите доказать. Библиотеки, написанные на таком принципе, уже ведь есть.
Получается, как про суслика, только наоборот: Суслика видишь? Да! А его нет!
uvelichitel:
> Что бы распарсить < <><> > вам уже понадобится хотя бы автомат со стеком
Хм... Кажется на это уже напоролся. А что это за стек, если по-простому? Типа сек открытых скобок "<", чтобы не запустаться какая ">" для какой "<"?
Denis Zagayevskiy: почему? Именно ЭТУ - уже распарсил. Есть метод ParseObject(string), вот для каждого такого { "name1" : "value1" } он и вызывается рекурсивно. Правда, на настоящей рекурсии (хотя бы в 2 уровня, а не 1) сразу глюк. Но теоретически вполне можно сделать, и я сделаю. Правда, здесь уже начинаются проблемы при моем сонной башке, ибо сложновато, но ничего, на свежую голову продолжу.
Алексей П: ну конечный автомат вроде уже понял. Сейчас попробую реализовать для JSON)) Уже могу считать себя специалистом по формальной грамматике, низшего ранга?
MiiNiPaa: давайте упростим задачу. Вернемся к goto.
Итак, у нас есть goto к метке, которая несколькими строчками ниже.
И нам, допустим, надо сразу все писать непосредственно в EXE-файл (допустим так адски важно быстродействие и простота)
Что мы делаем?
Распарсив goto, в EXE-файл пишем jmp 0; (пока что 0), при этом запомнив в коллекцию, что есть такой оператор goto, как называется метка и где именно в EXE-файле он находится.
А потом увидев эту метку, просто находим тот goto в коллекции и в соответствующий адрес EXE-файла ставим адрес метки.
Problems?
