Background: I'm creating kind of simplified pseudo-ORM for use in Django. Classes obviously use CamelCase convention, while Django app is underscored lowercase. Which leaves me with a few options:
Django ORM style: app_name_someclass
proper underscore style: app_name_some_class
as-is: app_name.SomeClass
possibly some other using different separators etc.
Are there any well established naming conventions for DynamoDB?
So far, from what I've seen in examples, it seems that it's free-for-all.
Following the examples in the AWS documentation here and here would lead to the following conventions:
Table names in Upper Camel Case, e.g. MyTable.
Attribute names also in Upper Camel Case, e.g. Id, ProductCategory etc.
Actually the examples are a bit inconsistent when it comes to acronym capitalization - with ISBN and Id in the first link and both CustomerID and CustomerId in the second link. Either style could be argued but I'd personally lean towards only capitalizing the first letter in an acronym. See here for more debate on this subject.
It's free for all. I name tables as "users", "secret-files", "seen-blog-posts", and their attributes as "user.name", "date.recent.iso", etc.
Related
I have subtly different entities that are important enough with respect to the relationships, flexibility, and expression of my schema that they warrant separate models.
How should I name/ case these?
a) Layerinput, Layerhidden, Layeroutput
b) Layer_Input, Layer_Hidden, Layer_Output
c) LayerInput, LayerHidden, LayerOutput
Right now I am leaning option a so that Django doesn't do anything too automagically incorrect with them, but that won't look great in documentation and code. Will use them with either DRF or graphql.
If you're referring to naming Classes, you should choose c) as shown in image below (obtained from https://docs.djangoproject.com/en/2.1/topics/db/models/#verbose-field-names).
If you're referring to the field_names (eg. name and age under the class CommonInfo in the figure above), then the convention for django is as followed:
According to PEP8 conventions,
Class names should normally use the CapWords convention.
These naming conventions are also followed in the Django framework. So you can choose the third option.
Use camelCase (option c), this helps you differentiate words in a variable while minimising the characters (as in option b)
Use this as a guide: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/
CamelCase (option c) is also useful because Django will know how to render your model names in the admin site. For example 'LayerInput' will appear correctly as 'Layer input' without you having to specify it anywhere.
Symfony uses a set of coding standards to set out for us how to program and what style we should use. My question is short and simple. I would like to know if symfony (together with doctrine ORM) has a similiar set of standards when it comes to building and structuring my database.
For example:
Should I use Camel Case?
Should my table name be user or users
Do I use capitals?
What charset is recommanded?
Basically, you do not need to care about database naming as Doctrine will do everything for you.
You should use Doctrine cli commands to generate your database schema based on your entities, or even better use Doctrine Migrations to maintain changes.
Should I use Camel Case?
For entity class names, I'd recommend sticking with PSR, so yes, use CamelCase.
Symfony by default uses underscore naming strategy, so entity CamelCase will be generated as table camel_case (if not manually overriden).
You can set another naming strategy, but the default underscore strategy is a fine choice.
Should my table name be user or users
user is a ANSI SQL reserved word, so I recommend using users. Or, if you prefer having entities in singular, try person instead.
Do I use capitals?
Again, Doctrine naming strategy will solve this for you. Moreover, eg postresql converts all table names and such identifiers to lowercase, so using capitals explicitly can cause problems.
What charset is recommanded?
Use UTF-8 (or more specifically utf8mb4 if needed). There are few reasons to use any other.
What is the best naming convention for instance, url and template names of Django models with more than one word?
Instances
yetanothermodel = YetAnotherModel()
yet_another_model = YetAnotherModel()
Url names
'yetanothermodel_detail'
'yet_another_model_detail'
Template names
'yetanothermodel_detail.html'
'yet_another_model_detail.html'
It is your personal choice. But if you are working in a team I would say you should be applying the Python PEP8 standard of coding; that way all members of the team are using the same process and naming conventions to write their code.
In this instance:
yet_another_model = YetAnotherModel()
Variables names should be lower-case, underscore separated. With class names using the camel casing naming convention.
and
'yet_another_model_detail'
Url names should be treat like a variable name or function name, lower-case separated with _ (underscores).
Templates:
Whilst there is no defined naming convention for templates I treat the naming the same as a function name. So in these cases I go for lower-case with underscore word separation.
I also keep the templates inside of the django apps (sometimes, I will have a templates directory which will have a directory for each app name).
I also stick the CRUD type at the end of the filename.
For example:
<app_div>/user_profile.html
<app_dir>/user_profile_update.html
<app_dir>/user_profile_view.html
<app_dir>/user_profile_delete.html
I need to create a RESTful webservice that allows for addressing entities by using different types of IDs. I will give you an example based on books (which is not what I need to process but I want to build a common understanding this way).
Books can be identifier by:
ISBN 13
ID
title
I can create a book by POSTing to /api/v1/books/The%20Bible. This book can then later be addressed by its ISBN /api/v1/books/12312312301 or ID /api/v1/books/A9471IZ1. If I implemented it this way I would need to analyze whatever identifier gets sent and convert it internally.
Is it 'legal' to add the type of identifier to the URL ? Like /api/v1/books/title/The%20Bible?
It seems that what you need is not simply retrieving resources, but searching for them by certain criteria (in your case, by ISBN, title or ID). In that case, rather than complicate your /books endpoint (which, ideally, should only returns books by ID), I'd create a separate /search function. You can then use it search for books by any field.
For example, you would have:
GET /search?title=bible
GET /search?isbn=12312312301
It can even be easily expanded to add more fields later on.
First: A RESTful URl should only contain nouns and not verbs. You can find a lot of best-practices online, as example: RESTful API Design: nouns are good, verbs are bad
One approach would be to detect the id/identifier in code.
The pattern would be, as you already mentioned:
GET /api/v1/books/{id}, like /api/v1/books/12312312301 or /api/v1/books/The%20Bible
Another approach, similar to this.lau_, would be with a query parameter. But I suggest to add the query parameter to the books URL (because only nouns, no verbs):
GET /api/v1/books?isbn=12312312301
The better solution? Not sure…
Because you are selecting “one book by id” (except title), rather than performing a query/search, I prefer the first approach (…/books should return “a collection of books” and .../books/{id} should return only one book).
But maybe someone has a better approach/idea?
Edit:
I suggest to avoid adding the identifier to the URL, it has “bad smell”. But is also a possible approach and I saw that a lot in other APIs. Let’s see if I can find some information on that, if its “ok” or should be avoided.
Edit 2:
See REST API DESIGN - Getting a resource through REST with different parameters but same url pattern and REST - supporting multiple possible identifiers
Let's say I have a method that returns a list of customers and as input has a list of states and list of sizes, something like
return customers where state in (NY, CA, TX) and size in (Small, Medium)
What would the best RESTFul URL that I should use? The problem that it is a query and does not point to a specific 'resource'. Here are some options that I am mulling over.
somesite.com/customers?state=NY,CA,TX&size=small,medium (old style)
somesite.com/customers/state/NY,CA,TX/size/small,medium
somesite.com/customers/state=NY,CA,TX/size=small,medium
somesite.com/customers/state(NY,CA,TX)/size(small,medium)
Option 1 - query params are intended for exactly that. Parameters for your query.
You are interested in a list of customers therefore the last "folder" should be "/customers". The fact that you want a subset of these and that that subset is variant depending on input, and in combination leads you to query params acting as filters. (Nothing else would make sense as you see by being compelled to ask the question).
The real question you have is whether the params are going to be inclusive or exclusive by default (i.e. AND or OR). That question has already been asked here if I can just find it...
I think #1 (somesite.com/customers?state=NY,CA,TX&size=small,medium) is the best of the bunch. The customers are the resources, and the query string is just placing restrictions on the resources being requested.
Personally, I'd use the 4th approach, but with the '+' sign instead of parenthesis:
somesite.com/customers/NY+CA+TX/small+medium
RESTful-style your Models are not necessarily all the RESTful Resources you should offer... You can add any number of (artificial) resources as you see fit, even ones that would require a JOINs from your Models.
For what it's worth, URI naming conventions has nothing to do with REST. In fact, if you define a way of constructing your application's URIs out-of-band as part of your API, you are violating a constraint of REST. See: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven