:::: MENU ::::
Apr 16, 2020    |      0 comments

HTTP Methods for RESTful Services

For so many times I am wondering which HTTP method should be used when I want to add, replace or modify a resource. Table below summarizes all the common methods and what they are doing.

HTTP VerbCRUDMeaning
GETReadGet the resource.
POSTCreateCreate NEW resource.
PATCHUpdate/ModifyModify part of the existing resource. Send only data you want to change.
PUTUpdate/ReplaceReplace the existing resource with new one.
DELETEDeleteDelete the resource

Source: https://www.restapitutorial.com/lessons/httpmethods.html

Mar 24, 2020    |      0 comments

Collecting IP addresses in Azure App Insights

When you want to collect IP addresses in Azure App Insights, you have to enable it. By default IP addresses are masked and you can only see some basic information like city or country.

If you want to enable this feature you can’t use Azure Portal, at least for now. The easiest way to do it, is to use Azure Resource Explorer.

  1. Go to https://resources.azure.com/ and pick proper AD you want to work with
  2. Click on Read/Write mode in top of the page.
  3. Find your App Insight instance by going into subscriptions / YOUR_SUBSCRIPTION / resourceGroups / YOUR_RESOURCE_GROUP / providers / microsoft.insights / components
  4. In Data tab click on Edit
  5. Remove the content of the properties property and put "DisableIpMasking": true
  6. Hit Patch button since we are changing the part of the resource definition.
  7. Done!

Example JSON payload

{
  "id": "/subscriptions/XXX/resourceGroups/XXX/providers/microsoft.insights/components/XXX",
  "name": "XXX",
  "type": "microsoft.insights/components",
  "location": "westeurope",
  "tags": {},
  "kind": "web",
  "etag": "\"XXX\"",
  "properties": {
    "DisableIpMasking": true
  }
}

Also this part of a documentation may be useful https://docs.microsoft.com/en-us/azure/azure-monitor/app/ip-collection

Sep 26, 2018    |      0 comments

Force https

RewriteEngine On

RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Mar 19, 2018    |      0 comments

Symfony directory structure comparison

Below you can find basic directory structure for Symfony 2.8, 3.4 using Symfony Installer and for Symfony 4 using Symfony Flex. There is no vendor content on each of the diagrams.

Comparison

Symfony 2.8

├── app
│   ├── Resources
│   │   └── views
│   ├── cache
│   ├── config
│   │   ├── config.yml
│   │   ├── parameters.yml
│   │   ├── routing.yml
│   │   ├── security.yml
│   │   └── services.yml
│   ├── logs
│   ├── AppKernel.php
│   ├── SymfonyRequirements.php
│   ├── console
│   └── phpunit.xml.dist
├── bin
│   ├── doctrine
│   ├── doctrine-dbal
│   ├── doctrine.php
│   └── security-checker
├── src
│   └── AppBundle
│       ├── Controller
│       ├── Tests
│       └── AppBundle.php
├── web
│   ├── bundles
│   ├── app.php
│   ├── app_dev.php
├── composer.json
└── composer.lock

Symfony 3.4

├── app
│   ├── Resources
│   │   └── views
│   ├── config
│   │   ├── config.yml
│   │   ├── parameters.yml
│   │   ├── routing.yml
│   │   ├── security.yml
│   │   └── services.yml
│   └── AppKernel.php
├── bin
│   ├── console
│   └── symfony_requirements
├── src
│   └── AppBundle
│       ├── Controller
│       └── AppBundle.php
├── tests
│   └── AppBundle
├── var
│   ├── cache
│   ├── logs
│   ├── sessions
│   ├── SymfonyRequirements.php
│   └── bootstrap.php.cache
├── web
│   ├── app.php
│   ├── app_dev.php
├── composer.json
├── composer.lock
└── phpunit.xml.dist

Symfony 4

├── assets
├── bin
│   ├── console
│   └── phpunit
├── config
│   ├── packages
│   │   ├── dev
│   │   ├── prod
│   │   ├── test
│   │   ├── doctrine.yaml
│   │   ├── doctrine_migrations.yaml
│   │   ├── framework.yaml
│   │   ├── routing.yaml
│   │   ├── security.yaml
│   │   └── twig.yaml
│   ├── routes
│   │   ├── dev
│   │   └── annotations.yaml
│   ├── bundles.php
│   ├── routes.yaml
│   ├── services.yaml
├── public
│   └── index.php
├── src
│   ├── Controller
│   ├── Entity
│   ├── Migrations
│   ├── Repository
│   └── Kernel.php
├── templates
├── tests
├── translations
├── var
│   ├── cache
│   └── log
├── composer.json
├── composer.lock
├── package.json
├── symfony.lock
└── webpack.config.js
Aug 10, 2017    |       2 comments

Wybór odpowiedniego kodu odpowiedzi HTTP – przestań utrudniać sobie życie!

Poniższy tekst jest mniej lub bardziej udanym tłumaczeniem artykułu Choosing an HTTP Status Code — Stop Making It Hard :).

Nie ma rzeczy prostszej niż zwrócenie kodu odpowiedzi HTTP. Strona się wyświetliła? Świetnie, zwróćmy kod 200. Strona nie istnieje? To kod 404. Przekierowujemy użytkownika na inną stronę? No to 302 albo 301.

Życie jest piękne dopóki ktoś powie Ci, że nie używasz REST-a. Nie możesz w nocy spać, bo zastanawiasz się, czy Twoja aplikacja zwraca zgodny z REST-em i zatwierdzony przez Roya Fieldinga kod odpowiedzi. Czy wystarczy 200? Czy powinien to być raczej 204 No Content? Nie, na pewno to powinien być 202 Accepted… a może jednak 201 Created?

To co komplikuje nam sytuację, to oficjalny standard HTTP/1.1, RFC, które pierwotnie powstało w 1997 roku (nie zawracaj sobie głowy RFC 2616, ani tym bardziej RFC 2068, zobacz RFC 7231). 1997 to rok, kiedy zacząłem przeglądać internet na Netscape Navigator i swoim modemie 33,6 kbps. To trochę jak używać Sztuki wojennej Sun Zi do współczesne strategii biznesowej. Nieśmiertelne rady, ale nie wyobrażam sobie jak wykorzystać pięć sposobów walki ogniem do testowania rynku.

Gdyby tylko istniał jakiś wizualny sposób na wybranie tylko tych istotnych kodów?

Proszę bardzo, internecie. Ten dzień nadszedł!

Continue Reading

Pages:‹12345›