Есть ли какие-либо инструкции по соглашению о присвоении имен для API REST? [закрытый]
Единственное , что вы можете сделать с помощью указателя void*, это привести его обратно к точно того же типа, что и указатель, приведенный к void* в первом место. Поведение при выполнении чего-либо еще не определено.
Что вы могли бы сделать в вашем случае, так это определить
class Base
{
public:
virtual ~Base() = default; // make me a polymorphic type and make
// polymorphic delete safe at the same time.
};
и сделать его базовым классом для Alpha и Beta. Затем обведите указатель Base*, а не void*, и поместите ваши dynamic_cast прямо на p.
Также отметим, что если вы объявите virtual void Speak() = 0; в Base, то ваш код в main станет просто
int main(){
Base* p = new Alpha;
p->Speak();
delete p; // ToDo - have a look at std::unique_ptr
}
Как правило, любые типы нежелательны. [ 1119]
6 ответов
Я думаю, вам следует избегать верблюжьих шапок. Нормой является использование строчных букв. Я также избегал бы подчеркивания и использовал бы вместо этого тире
Так что ваш URL должен выглядеть следующим образом (игнорируя проблемы дизайна, как вы просили: -))
api.service.com/hello-world/user-id/x
Look closely at URI's for ordinary web resources. Those are your template. Think of directory trees; use simple Linux-like file and directory names.
HelloWorld isn't a really good class of resources. It doesn't appear to be a "thing". It might be, but it isn't very noun-like. A greeting is a thing.
user-id might be a noun that you're fetching. It's doubtful, however, that the result of your request is only a user_id. It's much more likely that the result of the request is a User. Therefore, user is the noun you're fetching
www.example.com/greeting/user/x/
Makes sense to me. Focus on making your REST request a kind of noun phrase -- a path through a hierarchy (or taxonomy, or directory). Use the simplest nouns possible, avoiding noun phrases if possible.
Generally, compound noun phrases usually mean another step in your hierarchy. So you don't have /hello-world/user/ and /hello-universe/user/. You have /hello/world/user/ and hello/universe/user/. Or possibly /world/hello/user/ and /universe/hello/user/.
The point is to provide a navigation path among resources.
Я не думаю, что случай верблюда является проблемой в этом примере, но я предполагаю, что более RESTful соглашение об именах для приведенного выше примера будет:
api.service.com/helloWorld / userId / x
вместо того, чтобы делать userId параметром запроса (что совершенно законно), мой пример обозначает этот ресурс в IMO более RESTful способом.
Я бы сказал, что предпочтительно использовать как можно меньше специальных символов в URL-адресах REST. Одним из преимуществ REST является то, что он делает «интерфейс» службы легким для чтения. Случай с верблюдом или случай с Паскалем, вероятно, подходит для имен ресурсов (пользователей или пользователей). Я не думаю, что действительно существуют какие-то жесткие стандарты в отношении REST.
Кроме того, я думаю, что Гэндальф прав, в REST обычно чище не использовать параметры строки запроса, а вместо этого создавать пути, определяющие, с какими ресурсами вы хотите иметь дело. .
Нет. REST не имеет ничего общего с соглашениями об именах URI. Если вы включаете эти соглашения как часть вашего API вне канала, а не только через гипертекст, тогда ваш API не поддерживает RESTful.
Для получения дополнительной информации см. http://roy.gbiv.com / untangled / 2008 / rest-apis-must-be-hypertext-driven
Имена доменов не чувствительны к регистру, но остальная часть URI, безусловно, может. Большая ошибка предполагать, что в URI не учитывается регистр.