Comments 23
«Я человек простой, вижу минус, жму его.»
@Минусатор
@Минусатор
Я понимаю чем плох комментарий, но хоть бы один человек объяснил чем плоха статья.
Если вы правда не понимаете, то ответ прост — никому не интересно читать статью про «скачиваем библиотеку, по мануалу к ней пишем 10 строчек кода, готово».
Астрологи объявили неделю API на хабре.
Количество статей про RESTful API увеличено вдвое
Количество статей про RESTful API увеличено вдвое
А в чём преимущества перед другими решениями?
Как настроить сериализацию/десериализацию например, для JSON? Как дела обстоят с БД? Есть ли для дарта ORM какие-то? И как у дарта с инструментами для разработки, фреймворками и библиотеками?
Так-то я лучше возьму, например, Eve или просто Flask + плагины, если надо быстро. Или какое-нибудь решение на java/scala. И возьму не только, потому что знаю их хорошо, но ещё и потому что у эти языков очень богатая инфраструктура, есть куча материала в сети и есть приличные IDE для них.
Как настроить сериализацию/десериализацию например, для JSON? Как дела обстоят с БД? Есть ли для дарта ORM какие-то? И как у дарта с инструментами для разработки, фреймворками и библиотеками?
Так-то я лучше возьму, например, Eve или просто Flask + плагины, если надо быстро. Или какое-нибудь решение на java/scala. И возьму не только, потому что знаю их хорошо, но ещё и потому что у эти языков очень богатая инфраструктура, есть куча материала в сети и есть приличные IDE для них.
Уточните перед какими решениями вы хотите получить преимущества?
JSON — JSON.decode/encode
БД MySQL — библиотека SQLJocky, Mongo — Mongo-dart и Objectory ORM.
IDE — Webstorm как идеальный вариант, Atom как бесплатный.
По остальным вопросам есть моя же статья: Другой ответ на вопрос «Нужен ли мне Dart?».
Dart лучше того же GWT хотя бы тем, что тестировать можно не собирая проект, Dartium запускает Dart-код прямо в браузере. Если не брать в расчет GWT, то преимущество в том, что и клиент и сервер можно разработать на одном языке. Если сравнивать с JS, то, на мой взгляд, более приятный синтаксис и более удобный процесс разработки, про процесс рассказано в статье Сравнение процесса перехода Angular2 приложения до версии beta.0 на языках Dart и TypeScript.
JSON — JSON.decode/encode
БД MySQL — библиотека SQLJocky, Mongo — Mongo-dart и Objectory ORM.
IDE — Webstorm как идеальный вариант, Atom как бесплатный.
По остальным вопросам есть моя же статья: Другой ответ на вопрос «Нужен ли мне Dart?».
Dart лучше того же GWT хотя бы тем, что тестировать можно не собирая проект, Dartium запускает Dart-код прямо в браузере. Если не брать в расчет GWT, то преимущество в том, что и клиент и сервер можно разработать на одном языке. Если сравнивать с JS, то, на мой взгляд, более приятный синтаксис и более удобный процесс разработки, про процесс рассказано в статье Сравнение процесса перехода Angular2 приложения до версии beta.0 на языках Dart и TypeScript.
Dart лучше того же GWT
А еще лучше курить чем нюхать клей.
Если не брать в расчет GWT, то преимущество в том, что и клиент и сервер можно разработать на одном языке.
Трансляторов в JS код как грязи.
Если сравнивать с JS, то, на мой взгляд, более приятный синтаксис
Вы про ES 2015 что-нибудь слышали?
более удобный процесс разработки
Опять же, лично для вас.
PS: пожалуйста хоть как-то аргументируйте свои выводы.
тестировать можно не собирая проектЭто не аргумент?
Трансляторов в JS код как грязи.Дальше что?
Вы про ES 2015 что-нибудь слышали?Слышал и видел, а вы, видимо, видите только то, что хотите увидеть, я русским языком написал «на мой взгляд».
более удобный процесс разработкиНе лично для меня, для приличия зайдите по ссылке и прочитайте статью хотя бы по диагонали и отметьте для себя, что это перевод и что про удобство не я первый написал.
Опять же, лично для вас.
P.S. читайте внимательнее прежде чем писать.
Я писал некоторое время на Dart, и сейчас могу с полной уверенностью сказать, что тот стек технологий, который у меня сейчас просто унижает ваш Dart React, DevTools for Redux, React Developer Tools, Webpack, Wallaby, Сhimp и т.д.
Не лично для меня, для приличия зайдите по ссылке и прочитайте статью хотя бы по диагонали и отметьте для себя, что это перевод и что про удобство не я первый написал.Судя по вашим постам вы являетесь ярым адептом Dart'a, поэтому лично для вас.
просто унижает ваш DartОтвечу на это вашей же цитатой:
PS: пожалуйста хоть как-то аргументируйте свои выводы.
Судя по вашим постам вы являетесь ярым адептом Dart'a, поэтому лично для вас.Т.е. по вашему тот факт, что я пишу только о Dart, делает меня ярым адептом и нивелирует все те положительные отзывы, которые приведены в моих статьях или переводах и еще больше положительных отзывов и статей, которых нет среди моих статей и переводов, так получается? Это как утверждать, что врачи пишущие о пользе прививок делают сами прививки бесполезными.
JSON — JSON.decode/encode
Как у объекта отметить поля игнорируемыми при (де)сериализации объекта? Как переименовать поле? Как добавить метод как сериализуемое поле? Ну и т.д.
Просто на деле часто бывает так: сперва данные АПИ простые и легко перегоняются из и в JSON (ну или xml, не важно). Но рано или поздно наступает момент, когда нужно настроить отображение модели в JSON и правила восстановления модели из него. При этом, не хочется плодить лишние сущности (например, создать отдельный класс для отображения). И если в языке нет готовой библиотеки-маппера с возможностью настройки входного или выходного формата, то можно начать жалеть о своём выборе.
В качестве ОРМ для реляционных баз я увидел это. Но там даже нет отношений. ОРМ для монги умерло.
Как данные-то хранить? Писать запросы и парсить ответы вручную? Так легче взять питон с sqlalchemy и сэкономить кучу времени.
Уточните перед какими решениями вы хотите получить преимущества?
JSON: Ну, например, Jackson для java. Аннотациями можно настроить очень многое. На крайняк, можно написать свой плагин/модуль/datatype и т.д. Часто жалею, что аналогичной либы без зависимостей от веб-фреймворка нет для питона (или я искал плохо).
DB: Например, SQLAlchemy. sqlalchemy-core не реализует ОРМ, но предоставляет унифицированный интерфейс для подключения к БД и приятный DSL для формирования запросов. ORM тоже есть, и он довольно гибкий. Ещё пример — Hibernate или EclipseLink. Помимо кучи фич из JPA (который они реализуют), каждая имеет вдобавок свои полезные плюшки.
Так есть ли удобная либа/фреймворк для persistence-слоя? Будь то ОРМ, просто удобный инструмент для простой работой с реляционными БД или что-то для популярных nosql-баз? Понятно, что хибернейт или алхимия — большие и зрелые проекты, но есть ли в дарте хоть что-то приближённое?
Просто вот такие туторы в 10-30 строк кода хороши только в теории. Всё красиво, ёмко и просто. Но на практике малораспространённые языки/технлогии обычно сосут из-за отсутствия хороших библиотек. Может я и ошибаюсь, но тогда хочется увидеть пример сложного апи-сервиса, а не хелловорда.
Такое ощущение, что Вы перевели Getting Started к библиотеке rpc.
Вообще, вот то же самое в 18 строчках на JS (или 14 не считая пустые). Я не могу говорить за всех, но имхо, этот код понятнее и проще.
Вообще, вот то же самое в 18 строчках на JS (или 14 не считая пустые). Я не могу говорить за всех, но имхо, этот код понятнее и проще.
const app = require('express')();
const bodyParser = require('body-parser');
app.use(bodyParser.json());
var animals = [];
const findAnimalById = (id) => animals.filter(a => a.id === Number(id))[0];
const removeAnimal = (id) => animals = animals.filter(a => a.id !== Number(id));
const makeAnimal = (params) =>
animals.push(Object.assign({ id: animals.length + 1 }, params)) &&
animals[animals.length - 1];
app.get('/list', (req, res) => res.json(animals));
app.get('/', (req, res) => res.json(findAnimalById(req.query.id)));
app.post('/', (req, res) => res.json(makeAnimal(req.body)));
app.delete('/', (req, res) => res.json(removeAnimal(req.query.id)))
app.listen(3000);
Я с вами не согласен, мне проще и понятнее два файлика общим объёмом 25 строк:
и
import 'dart:io';
import 'package:logging/logging.dart';
import 'package:rpc/rpc.dart';
import '../lib/server/api.dart';
final ApiServer apiServer = new ApiServer(prettyPrint: true);
main() async {
apiServer.addApi(new MyApi());
HttpServer server = await HttpServer.bind(InternetAddress.ANY_IP_V4, 8080);
server.listen(apiServer.httpRequestHandler);
}
и
@ApiClass(version: 'v1')
class MyApi {
List _animals = [];
@ApiMethod(path: 'animals')
List<Animal> getAnimals() => _animals;
@ApiMethod(path: 'animals', method: 'POST')
Animal postAnimal(Animal animal) {
_animals.add(animal);
return animal;
}
}
package main
import (
"encoding/json"
"flag"
"net/http"
"strconv"
)
var addr = flag.String("http", ":3000", "http service address")
type Animal struct {
ID int
Name string
}
func main() {
animals := []Animal{
{0, "python"},
{1, "sad panda"},
{2, "candy bear"},
{3, "camel"},
{4, "cat is fine too"},
}
flag.Parse()
http.HandleFunc("/list", func(w http.ResponseWriter, _ *http.Request) {
json.NewEncoder(w).Encode(animals)
})
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
defer func() {
if err := recover(); err != nil {
http.Error(w, http.StatusText(http.StatusBadRequest),
http.StatusBadRequest)
}
}()
id, _ := strconv.Atoi(req.FormValue("ID"))
switch req.Method {
case "GET":
json.NewEncoder(w).Encode(animals[id])
case "POST":
animals = append(animals, Animal{
len(animals),
req.FormValue("Name")})
case "DELETE":
animals = append(animals[:id], animals[id+1:]...)
}
})
panic(http.ListenAndServe(*addr, nil))
}
А вообще различные примеры hello world для http можно посмотреть тут
REST, по-сути, является математической формализацией протокола передачи состояния между двумя компонентами информационной системы. Знать HTTP, но не понимать REST это как знать SQL, но не понимать реляционной модели данных (реляционной алгебры/исчисления, видов нормализации данных, т.д.)
Однако же в данной заметке вообще не идёт речи о REST. Тут идёт речь о том, как с помощью конкретной RPC-библиотеки можно описать обработчики запросов. Это как статья «Строим ракету» рассказывала бы о том, как скачать кряк на SolidWorks. Пикантности добавляет тот факт, что REST как архитектурный принцип как раз «возвражает» концепции RPC, вносит свои ограничения на виды запросов, REST-API — это очень конкретное подмножество RPC-API. (Не очень понимаю, почему библиотека называется именно RPC, а не HTTP, или она действительно абстрагирована от низлежащих протоколов и может работать над любым?)
Вся эта мода на аббревиатуры, термины, «новые принципы» и т.п. даёт ощущение нахождения в тренде, в теме. Но если вы сами не столкнулись с проблемами, которые решает очередная аббревиатура или принцип, если не поняли этой проблемы, то стОит пока воздержаться от внедрения принципа в свой проект.
Однако же в данной заметке вообще не идёт речи о REST. Тут идёт речь о том, как с помощью конкретной RPC-библиотеки можно описать обработчики запросов. Это как статья «Строим ракету» рассказывала бы о том, как скачать кряк на SolidWorks. Пикантности добавляет тот факт, что REST как архитектурный принцип как раз «возвражает» концепции RPC, вносит свои ограничения на виды запросов, REST-API — это очень конкретное подмножество RPC-API. (Не очень понимаю, почему библиотека называется именно RPC, а не HTTP, или она действительно абстрагирована от низлежащих протоколов и может работать над любым?)
Вся эта мода на аббревиатуры, термины, «новые принципы» и т.п. даёт ощущение нахождения в тренде, в теме. Но если вы сами не столкнулись с проблемами, которые решает очередная аббревиатура или принцип, если не поняли этой проблемы, то стОит пока воздержаться от внедрения принципа в свой проект.
Sign up to leave a comment.
Создаём RESTful API с помощью Dart за несколько минут