http - PUT vs. POST w REST - 365airsoft.com\n32 Pytanie: PUT vs. POST w REST\npytanie utworzone w Sat, Jul 22, 2017 12:00 AM\nZgodnie ze specyfikacją HTTP /1.1:\nMetoda POST służy do żądania, aby serwer pochodzenia zaakceptował obiekt zawarty w żądaniu jako nowy podrzędny zasób zidentyfikowany przez Request-URI w Request-Line\nInnymi słowy, POST służy do tworzenia .\nMetoda PUT wymaga, aby obiekt zamknięty był przechowywany pod dostarczonym numerem Request-URI. Jeśli Request-URI odnosi się do już istniejącego zasobu, POWINNA być traktowana jako zmodyfikowana wersja tego zasobu serwer pochodzenia. Jeśli Request-URI nie wskazuje istniejącego zasobu, a identyfikator URI może zostać zdefiniowany jako nowy zasób przez żądającego agenta użytkownika, serwer pochodzenia może utworzyć zasób przy użyciu tego identyfikatora URI. ”\nOznacza to, że PUT służy do utworzenia lub aktualizacji .\nWięc, który z nich powinien zostać użyty do utworzenia zasobu? Albo trzeba obsługiwać oba?\nPomocne może być użycie definicji w HTTPbis - Roy włożył sporo pracy w ich wyjaśnienie. Zobacz: tools.ietf.org/html/…\nAby sprowadzić komentarz @ MarkNottinghama do najnowszej wersji, oto POST i PUT , jak zdefiniowano w HTTPbis.\nWydaje mi się, że ta debata powstała w wyniku powszechnego upraszczania REST poprzez opisywanie metod HTTP w zakresie operacji CRUD.\nNiestety pierwsze odpowiedzi są błędne co do POST. Sprawdź moją odpowiedź, aby uzyskać lepsze wyjaśnienie różnic: stackoverflow.com/a/18243587/2458234\nPUT i POST są niebezpiecznymi metodami. Jednak PUT jest idempotentny, podczas gdy POST nie. - Zobacz więcej na: restcookbook.com/HTTP%20Methods/put-vs-post /…\nZarówno PUT, jak i POST mogą być używane do tworzenia.\nMusisz zapytać „do czego wykonujesz akcję?” rozróżnić, czego powinieneś używać. Załóżmy, że projektujesz API do zadawania pytań. Jeśli chcesz użyć POST, możesz to zrobić na liście pytań. Jeśli chcesz użyć PUT, zrobiłbyś to na konkretne pytanie.\nMożna użyć wspaniałego obu, więc którego należy użyć w moim projekcie RESTful:\nTo, co jest używane, zależy od Ciebie. Ale pamiętaj, aby użyć właściwego w zależności od tego, do którego obiektu odwołujesz się w żądaniu.\nCzy nazywasz obiekty URL, które tworzysz jawnie, czy też pozwalasz serwerowi zdecydować? Jeśli je nazwiesz, użyj PUT. Jeśli pozwolisz serwerowi zdecydować, użyj POST.\nPUT jest idempotentny, więc jeśli dwa razy PUT obiektu, to nie ma wpływu. Jest to dobra właściwość, więc używałbym PUT, gdy to możliwe.\nMożesz zaktualizować lub utworzyć zasób z PUT z tym samymadres URL obiektu\nDzięki POST możesz mieć 2 żądania przychodzące w tym samym czasie, zmieniając adres URL i mogą aktualizować różne części obiektu.\nNapisałem następujące słowa jako część innej odpowiedzi na temat SO dotyczącej tego :\nZauważ, że następujący błąd jest następujący:\nJeśli adres URL nie został jeszcze utworzony, ty nie powinien używać POST do jego utworzenia podczas określania nazwy. To powinno spowoduje błąd „Nie znaleziono zasobu” ponieważ <new_question> nie istnieje jeszcze. Powinieneś wpisać <new_question> Najpierw zasób na serwerze.\nMożna jednak zrobić coś takiego aby utworzyć zasoby przy użyciu POST:\nZauważ, że w tym przypadku zasób nazwa nie jest określona, nowe obiekty Ścieżka URL zostałaby ci zwrócona.\nSłuży do tworzenia zasobu lub Przepisz to. Podczas gdy określisz zasoby nowy adres URL.\nMyślę, że nie można wystarczająco podkreślić faktu, że PUT jest idempotentny: jeśli sieć jest nieudana, a klient nie jest pewien, czy jego żądanie się udało, może po prostu wysłać to drugi (lub 100) czas i jest to gwarantowane przez specyfikację HTTP, która ma dokładnie taki sam efekt jak jednorazowe wysłanie.\n@ Jörg W Mittag: Nie jest konieczne. Drugi raz może zwrócić 409 Konflikt lub coś, jeśli żądanie zostało w międzyczasie zmodyfikowane (przez innego użytkownika lub pierwsze samo żądanie, które przeszło).\nJeśli się nie mylę, powinniśmy podkreślić, że PUT jest zdefiniowane , aby być idempotentnym. Nadal musisz napisać swój serwer w taki sposób, aby PUT zachowywał się poprawnie, tak? Być może lepiej powiedzieć „PUT powoduje, że transport zakłada idempotencję, co może wpływać na zachowanie transportu, np. Buforowanie.”\n@ JörgWMittag Idempotence catchphrase? Co powiesz na „Wyślij i wyślij i wyślij do mojego przyjaciela, to w końcu nie ma znaczenia.”\nMyśli o nich jako: PUT = insert lub update; POST = wstaw. Więc kiedy tworzysz dwa PUT - dostajesz jeden nowy rekord, kiedy robisz dwa POST - dostajesz dwa nowe rekordy.\nMożesz znaleźć twierdzenia w sieci, które mówią\nPOST należy użyć do utworzenia zasobu i PUT należy użyć do zmodyfikowania\nPUT należy użyć do utworzenia zasobu i POST powinien zostać użyty do zmodyfikowania go\nŻadne nie jest w porządku.\nLepiej jest wybierać między PUT i POST na podstawie idempotence akcji.\nPUT oznacza umieszczenie zasobu - całkowicie zastępując wszystko, co jest dostępne pod danym adresem URL, inną rzeczą. Z definicji PUT jest idempotentny. Zrób to tyle razy, ile chcesz, a wynik jest taki sam. x=5 jest idempotentny. Możesz ZESTAWIĆ zasób, niezależnie od tego, czy wcześniej istniał, czy nie (np. Utworzyć lub zaktualizować)!\nPOST aktualizuje zasób, dodaje zasób pomocniczy lub powoduje zmianę. POSTnie jest idempotentny, tak jak x++ nie jest idempotentny.\nPrzez ten argument PUT służy do tworzenia, gdy znasz adres URL rzeczy, którą utworzysz. POST może być używany do tworzenia, gdy znasz adres URL „fabryki” lub menedżera dla kategorii rzeczy, które chcesz utworzyć.\nZgadzam się, niezależnie od tego, gdzie chodzi o idempotence, powinno to przebić wszelkie inne obawy, ponieważ popełnienie tego błędu może spowodować wiele nieoczekiwanych błędów.\nJeśli POST może zaktualizować zasób, jak to nie jest idempotentne? Jeśli zmieniam wiek uczniów za pomocą PUT i robię to 10 razy, wiek uczniów jest taki sam, gdybym to zrobił raz.\n@ Schneider, w tym przypadku twój serwer dokłada dodatkowych starań, aby zagwarantować idempotence, ale nie reklamuje go. Przeglądarki nadal ostrzegają użytkownika, jeśli spróbują przeładować takie żądanie POST.\n@ Schneider POST może utworzyć zasób pomocniczy; dlatego możesz POST do kolekcji, jak POST /raporty wydatków i utworzyłby tyle podmiotów (raportów wydatków) na serwerze, ile ilości wysłanych żądań, nawet jeśli są one całkowicie podobne . Pomyśl o tym, jak wstawić ten sam wiersz do tabeli DB (/raporty wydatków) z automatycznie zwiększanym kluczem podstawowym. Dane pozostają takie same, klucz (w tym przypadku URI) jest generowany przez serwer i jest inny dla każdej innej wstawki (żądania). Tak więc efekt POST może być idempotentny, ale także może nie. Dlatego POST jest nie idempotentny.\nPowiedzmy, że mamy jednostki, które mogą mieć dwie właściwości - name i date. Jeśli mamy podmiot z istniejącym name i date, ale następnie wysyłamy do niego żądania określając tylko name, właściwym zachowaniem PUT byłoby zatarcie date jednostki, podczas gdy POST może zaktualizować tylko określone właściwości, pozostawiając nieokreślone właściwości tak jak przed wniosek został złożony. Czy to brzmi poprawnie /rozsądnie, czy też jest to niewłaściwe użycie PUT (widziałem odniesienia do PATCH , które wydaje się bardziej odpowiednie, ale jeszcze nie istnieje )?\nPOST na adres URL tworzy zasób podrzędny na zdefiniowanym serwerze URL.\nPUT na adres URL tworzy /zastępuje zasób w całości przy użyciu adresu URL zdefiniowanego klienta.\nPATCH do adresu URL aktualizuje część zasobu przy zdefiniowanym adresie URL klienta.\nOdpowiednia specyfikacja dla PUT i POST to RFC 2616 §9.5 ff.\nPOST tworzy zasób podrzędny , więc POST na /items tworzy zasoby, które znajdują się pod zasobem /items. Na przykład. /items/1. Dwukrotne wysłanie tego samego pakietu pocztowego spowoduje utworzenie dwóch zasobów.\nPUT służy do tworzenia lub zastępowania zasobu przy użyciu adresu URL znanego przez klienta .\nDlatego: PUT jest tylko kandydatem do CREATE, gdzie klient zna adres URL przed utworzeniem zasobu. Na przykład. /blogs/nigel/entry/when_to_use_post_vs_put ponieważ tytuł jest używany jako klucz zasobu\nPUT zastępuje zasób w znanym adresie URL, jeśli już istnieje, więc dwukrotne wysłanie tego samego żądania nie ma wpływu. Innymi słowy, połączenia do PUT są idempotentne .\nRFC czyta tak:\nPodstawowa różnica między żądaniami POST i PUT znajduje odzwierciedlenie w innym znaczeniu of URI żądania. Identyfikator URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamkniętą jednostkę. Ten zasób może być procesem akceptującym dane, bramą do innego protokołu lub oddzielną jednostką, która akceptuje adnotacje. W przeciwieństwie do tego, URI w żądaniu PUT identyfikuje jednostkę zamkniętą w żądaniu - agent użytkownika wie, jaki jest adres URI, a serwer NIE MOŻE próbować zastosować żądania do innego zasobu. Jeśli serwer chce, aby żądanie zostało zastosowane do innego URI,\nUwaga: PUT jest najczęściej używany do aktualizacji zasobów (zastępując je w całości), ale ostatnio pojawia się ruch w kierunku używania PATCH do aktualizowania istniejących zasobów, ponieważ PUT określa, że zastępuje całość ratunek. RFC 5789.\nAktualizacja 2018 : istnieje przypadek, w którym można uniknąć PUT. Zobacz „REST bez PUT”\nW technice „REST without PUT” chodzi o to, aby konsumenci byli zmuszony do opublikowania nowych „nounified” zasobów żądania. Jak ustalono wcześniej zmiana adresu pocztowego klienta jest POST na nowy Zasób „ChangeOfAddress”, a nie PUT zasobu „Customer” za pomocą inna wartość pola adresu pocztowego.\nzaczerpnięte z Projektowanie interfejsu API REST - Modelowanie zasobów przez Prakash Subramaniam z Myśli\nWymusza to na interfejsie API unikanie problemów z przejściem od stanu z wieloma klientami aktualizującymi pojedynczy zasób i ładniej pasującymi do źródeł zdarzeń i CQRS. Gdy praca jest wykonywana asynchronicznie, POSTowanie transformacji i oczekiwanie na jej zastosowanie wydaje się właściwe.\nLub z drugiej strony ogrodzenia: PUT, jeśli klient określa adres zasobu wynikowego, POST, jeśli serwer to robi.\nMyślę, że ta odpowiedź powinna być edytowana, aby było bardziej jasne, co @DanMan wskazał w bardzo prosty sposób. Najbardziej cenne jest tutaj notatka na końcu, stwierdzająca, że PUT powinien być używany tylko do zastąpienia całego zasobu.\nPATCH nie jest realistyczną opcją przez co najmniej kilka lat, ale zgadzam się z ideologią.\nPróbuję zrozumieć, ale użycie PUT do stworzenia czegoś miałoby sens tylko wtedy, gdyby klient wiedział na pewno, że zasób jeszcze nie istnieje, prawda? Podążając za przykładem bloga, powiedzmy, że stworzyłeś setki postów na blogu w ciągu kilku lat, a potem przypadkowo wybierzesz ten sam tytuł, co dwa lata temu. Teraz odszedłeś i zastąpiłeś ten post, który nie był przeznaczony. Tak więc użycie PUT do stworzenia wymagałoby od klienta śledzenia tego, co zostało zrobione, a co nie, a także może prowadzić do wypadków i niezamierzonych skutków ubocznych, a także mieć trasy, które wykonują dwie zupełnie różne rzeczy?\nMasz rację. WPROWADZENIE wpisu na blogu w tym samym adresie URL, co istniejący, spowodowałoby aktualizację tego istniejącego posta (chociaż można oczywiście sprawdzić najpierw GET). Wskazuje to, dlaczego złym pomysłem byłoby używanie tytułu jako adresu URL. Działałoby to jednak wszędzie tam, gdzie w danych był naturalny klucz ... co w moim doświadczeniu jest rzadkie. Lub jeśli użyłeś identyfikatorów GUI\nMożna wykonać zarówno PUT, jak i POST w następujący sposób:\nTworzy THE nowy zasób z newResourceId jako identyfikatorem, pod identyfikatorem URI zasobów / lub kolekcją .\nTworzy nowy zasób w ramach identyfikatora URI zasobów / lub . Zwykle identyfikator jest zwracany przez serwer.\nCzy można tylko wykonać PUT w następujący sposób:\nAktualizuje zasób za pomocą existingResourceId jako identyfikatora, w URI zasobów /lub kolekcji .\nJeśli chodzi o REST i URI jako ogólne, masz ogólny w lewym i określonym w prawym . Ogólne są zwykle nazywane kolekcjami , a bardziej specyficzne elementy można nazwać zasobami . Pamiętaj, że zasób może zawierać kolekcję .\n< - ogólne - specyficzne - >\nGdy używasz POST, zawsze odwołujesz się do kolekcji , więc kiedy mówisz:\npublikujesz nowego użytkownika w kolekcji użytkowników .\nJeśli przejdziesz dalej i spróbujesz czegoś takiego:\nbędzie działać, ale semantycznie mówisz, że chcesz dodać zasób do john kolekcji pod użytkownikami kolekcja .\nGdy używasz PUT, odnosisz się do zasobu lub pojedynczego elementu, ewentualnie do kolekcji . Więc kiedy mówisz:\npowiadamiasz serwer o aktualizacji lub utwórz, jeśli nie istnieje, zasób john pod użytkownikami kolekcja .\nPozwólcie, że podkreślę niektóre ważne części specyfikacji:\nMetoda POST służy do zażądania od serwera źródłowego zaakceptowania encji zawartej w żądaniu jako nowego podrzędnego zasobu zidentyfikowanego przez URI żądania w linii żądania\nStąd tworzy nowy zasób w kolekcji .\nMetoda PUT wymaga, aby załączony podmiot był przechowywany w dostarczonym URI żądania. Jeśli identyfikator URI żądania odnosi się do już istniejącego zasobu , dołączony obiekt POWINIEN być uważany za zmodyfikowaną wersję tego, który znajduje się na serwerze pochodzenia. Jeśli identyfikator żądania URI nie wskazuje istniejącego zasobu , a identyfikator URI jest zdolny do zdefiniowania jako nowy zasób przez żądającego agenta użytkownika, serwer pochodzenia może utworzyć zasób z tym URI. ”\nStwórz zatem lub zaktualizuj na podstawie istnienia zasobu .\nSpecyfikacja HTTP /1.1\nJednolite identyfikatory zasobów (URI): ogólna składnia i semantyka\nTen post był dla mnie pomocny w zrozumieniu, że POST dodaje „coś” jako dziecko do podanej kolekcji (URI), podczas gdy PUT wyraźnie definiuje „coś” w podana lokalizacja URI.\nMyślę, że to najlepsza odpowiedź: żaden z tych "POSTów nie może aktualizować nonsensów zasobów". Podoba mi się twoje stwierdzenie: „Aktualizacja może być wykonana tylko za pomocą PUT”.\nNie, PUT nie jest przeznaczony do aktualizacji ani tworzenia. To jest do wymiany. Zauważ, że nie możesz niczego zastąpić czymś w celu stworzenia.\n@ 7hi4g0 PUT służy do aktualizacji z pełnym zastąpieniem, innymi słowy, zastępuje. Nic nie zastępujesz czymś lub czymś zupełnie nowym. PP nie jest do tego zdolnyg niewielka zmiana (chyba, że klient wprowadzi tę drobną zmianę i zapewni całą nową wersję, nawet to, co pozostanie bez zmian). W przypadku modyfikacji częściowej PATCH jest metodą z wyboru.\n@ thecoshman Mógłbyś, ale nie byłoby to zbyt jasne, że tworzenie jest tam również opisane. W tym przypadku lepiej być wyraźnym.\nChciałbym dodać moją „pragmatyczną” radę. Użyj PUT, gdy znasz „id”, o który można zapisać zapisywany obiekt. Używanie PUT nie będzie działało zbyt dobrze, jeśli potrzebujesz, na przykład, wygenerowanego identyfikatora bazy danych, który ma zostać zwrócony w celu późniejszego wyszukiwania lub aktualizacji.\nWięc: Aby zapisać istniejącego użytkownika lub taki, w którym klient generuje identyfikator i zweryfikowano, że identyfikator jest unikalny:\nW przeciwnym razie użyj POST, aby początkowo utworzyć obiekt, a PUT, aby zaktualizować obiekt:\nWłaściwie powinno to być POST /users. (Należy pamiętać, że /users jest liczbą mnogą.) Ma to wpływ na utworzenie nowego użytkownika i uczynienie go zasobem podrzędnym kolekcji /users.\n@ DavidRR, aby być uczciwym, jak obsługiwać grupy to kolejna debata. GET /users ma sens, czyta tak, jak chcesz, ale byłbym w porządku z GET /user/<id> lub POST /user (z ładunkiem dla nowego użytkownika), ponieważ czyta poprawnie „pobierz mnie 5” jest nieparzysty, ale „pobierz mnie 5” to więcej naturalny. Prawdopodobnie jednak nadal spadłbym na stronę pluralizacji :)\nPOST oznacza „stwórz nowy” jak w „Oto dane wejściowe do utworzenia użytkownika, stwórz go dla mnie”.\nPUT oznacza „wstaw, zamień jeśli już istnieje” jak w „Oto dane dla użytkownika 5”.\nMożesz POST do example.com/users, ponieważ nie znasz jeszcze adresu URL użytkownika, chcesz, aby serwer go utworzył.\nPUT trafiasz do example.com/users/id, ponieważ chcesz zastąpić /utworzyć konkretnego użytkownika.\nDwukrotne testowanie POST przy użyciu tych samych danych oznacza utworzenie dwóch identycznych użytkowników o różnych identyfikatorach. Dwukrotne wprowadzenie tych samych danych powoduje, że użytkownik staje się pierwszym i aktualizuje go do tego samego stanu po raz drugi (bez zmian). Ponieważ po PUT kończysz z tym samym stanem, niezależnie od tego, ile razy go wykonasz, mówi się, że za każdym razem jest „równie silny” - idempotentny. Jest to przydatne do automatycznego ponawiania żądań. Nigdy więcej „czy na pewno chcesz wysłać ponownie” po naciśnięciu przycisku Wstecz w przeglądarce.\nOgólną radą jest używanie POST, gdy serwer musi kontrolować generowanie adresów URL zasobów. Użyj PUT inaczej. Wolisz PUT niż POST.\nSloppiness może spowodować, że będzie powszechnie nauczane, że są tylko dwa czasowniki, których potrzebujesz: GET i POST. GET, aby uzyskać, POST do zmiany. Nawet PUT i DELETE były wykonywane przy użyciu POST. Pytanie o to, co naprawdę oznacza PUT 25 lat później, może na początku źle się nauczyliśmy. Popularność REST doprowadziła ludzi do powrotu do podstaw, w których musimy teraz oduczyć się złych błędów. POST był nadużywany, a teraz powszechnie nauczany nieprawidłowo. Najlepsza część: „POSTowanie dwa razy za pomocą tych samych danych oznacza utworzenie dwóch identycznych [zasobów]”. Świetny punkt!\nJak można użyć PUT do utworzenia rekordu według ID, jak w przykładzie user 5, jeśli jeszcze nie istnieje? Nie masz na myśli update, replace if already exists? lub coś\n@ Coulton: Miałem na myśli to, co napisałem. Wstawiasz użytkownika 5, jeśli PUT do /users /5 i # 5 jeszcze nie istnieje.\n@ Coulton: I PUT można również użyć do zastąpienia wartości istniejącego zasobu w całości.\n"Preferuj PUT ponad POST" ... staraj się to uzasadnić?\nUżyj POST do utworzenia i PUT do aktualizacji. Tak właśnie robi Ruby on Rails.\nPOST /items dodaje nowy element do już zdefiniowanego zasobu („element”). Nie odpowiada, jak mówi odpowiedź, „tworzeniu grupy”. Nie rozumiem, dlaczego ma 12 głosów.\nTo jest uczciwa wskazówka, ale nadmierne uproszczenie. Jak wspominają inne odpowiedzi, obie metody mogą być używane zarówno do tworzenia, jak i aktualizacji.\nZgadzam się z odpowiedzią z niewielką modyfikacją. Użyj POST do utworzenia i PUT, aby całkowicie zaktualizować zasób. W przypadku częściowych aktualizacji możemy użyć PUT lub PATCH. Powiedzmy, że chcemy zaktualizować status grupy. Możemy użyć PUT /grup /1 /status ze statusem to ładunek żądania lub PATCH /grupy /1 ze szczegółami dotyczącymi akcji w ładunku\nNależy również wyjaśnić, że PUT /items/42 jest również ważne dla tworzenia zasobu, , ale tylko wtedy, gdy klient ma przywilej nazywanie zasobu . (Czy Railsy pozwalają klientowi na to uprawnienie do nadawania nazw?)\nreplace is better word for PUT patch jest do aktualizacji\nOba są używane do transmisji danych między klientem a serwerem, ale są między nimi subtelne różnice, którymi są:\nPodsumowując: POST dla insertów, PUT dla aktualizacji\n@ MobileMon Nie, metody REST nie są CRUD.\nPowiedziałbym, że PUT for UPSERTS\nJeśli masz jakiekolwiek wątpliwości dotyczące implementacji REST w HTTP, zawsze możesz spojrzeć na Specyfikacja Atom Publication Protocol (AtomPub) . AtomPub jest standardem do pisania RESTful webservices z HTTP, który został opracowany przez wiele luminarzy HTTP i REST, z pewnym wkładem Roy'a Fieldinga, wynalazcy REST i (współ) wynalazcy samego HTTP.\nW rzeczywistości możesz nawet korzystać z AtomPub bezpośrednio. Choć pochodzi ze społeczności blogów, w żaden sposób nie ogranicza się do blogowania: jest to ogólny protokół RESTfully współdziałający z dowolnymi (zagnieżdżonymi) kolekcjami dowolnych zasobów za pośrednictwem protokołu HTTP. Jeśli możesz reprezentować swoją aplikację jako zagnieżdżoną kolekcję zasobów, możesz po prostu użyć AtomPub i nie martwić się o to, czy użyć PUT lub POST, jakie kody stanu HTTP powrócić i wszystkie te szczegóły.\nTo jest to, co AtomPub ma do powiedzenia na temat tworzenia zasobów (sekcja 9.2):\nNie ma nic złego w zezwalaniu PUT na tworzenie zasobów. Pamiętaj tylko, że oznacza to, że klient podaje adres URL.\nCoś jest nie tak z zezwoleniem PUT na tworzenie zasobów: klient podaje adres URL. To zadanie serwera!\n@ Joshcodes Tworzenie identyfikatorów klienta nie zawsze jest zadaniem serwera. Coraz częściej widziałem projekty, które pozwalały klientom generować pewien rodzaj UUID jako identyfikator zasobu. Ten projekt nadaje się szczególnie do zwiększenia skali.\n@ JustinOhms Zgadzam się z twoim punktem na temat identyfikatorów wygenerowanych przez klienta (uwaga: wszystkie systemy zaprojektowane przeze mnie od około 2008 roku wymagają od klienta utworzenia identyfikatora jako UUID /Guid ). Nie oznacza to, że klient powinien podać adres URL.\nTak, jeśli zasób już istnieje, użyj PUT. Jednak prawie we wszystkich przypadkach zasoby powinny być tworzone za pomocą POST, a klient nie powinien podawać adresu URL. Roy Fielding zgadza się z tym stwierdzeniem FWIW: roy.gbiv. com /untangled /2008 /rest-apis-must-be-hypertext sterowany\nDecyzja, czy użyć PUT lub POST do utworzenia zasobu na serwerze za pomocą interfejsu API REST HTTP +, zależy od tego, kto jest właścicielem struktury adresu URL. Znajomość klienta lub udział w definiowaniu , struktura URL jest niepotrzebnym sprzężeniem podobnym do niepożądanych sprzężeń, które powstały z SOA. Uciekające typy sprzęgieł są powodem, dla którego REST jest tak popularny. Dlatego właściwą metodą jest POST. Istnieją wyjątki od tej reguły, które występują, gdy klient chce zachować kontrolę nad strukturą lokalizacji zasobów, które wdraża. Jest to rzadkie i prawdopodobnie oznacza, że coś innego jest nie tak.\nW tym momencie niektórzy ludzie twierdzą, że jeśli URL RESTful jest używany, klient zna adres URL zasobu i dlatego PUT jest dopuszczalne. W końcu to dlatego kanoniczne, znormalizowane, Ruby on Rails, adresy URL Django są ważne, spójrz na Twitter API… bla bla bla. Ci ludzie muszą zrozumieć nie ma czegoś takiego jak Restful-URL i Roy Fielding sam stwierdza, że :\nInterfejs API REST nie może definiować stałych nazw zasobów ani hierarchii (an obvsprzężenie klienta i serwera). Serwery muszą mieć wolność kontrolować własną przestrzeń nazw. Zamiast tego zezwól serwerom na instruowanie klientów na temat konstruowania odpowiednich URI, takich jak w HTML formularze i szablony URI, definiując te instrukcje w mediach typy i powiązania relacji. [Niepowodzenie oznacza, że klienci są przyjmując strukturę zasobów z powodu informacji poza pasmem, takich jak standard specyficzny dla domeny, który jest odpowiednikiem zorientowanym na dane Funkcjonalne połączenie RPC].\nhttp://roy.gbiv.com/untangled /2008 /rest-apis-must-be-hypertext sterowany\nPomysł RESTful-URL jest w rzeczywistości naruszeniem REST, ponieważ serwer jest odpowiedzialny za strukturę adresu URL i powinien mieć swobodę decydowania, jak go użyć, aby uniknąć sprzężenia. Jeśli to wprowadzi w błąd, przeczytaj o znaczeniu odkrywania samego siebie w projektowaniu API.\nUżywanie POST do tworzenia zasobów przychodzi z uwzględnieniem projektu, ponieważ POST nie jest idempotentny. Oznacza to, że wielokrotne powtarzanie POST nie gwarantuje za każdym razem takiego samego zachowania. To przeraża ludzi do używania PUT do tworzenia zasobów, kiedy nie powinni. Wiedzą, że to źle (POST to CREATE), ale i tak to robią, ponieważ nie wiedzą, jak rozwiązać ten problem. Ta obawa została wykazana w następującej sytuacji:\nKlient POST nowego zasobu na serwer.\nKlient nigdy nie otrzyma odpowiedzi.\nKlient nie ma adresu URL dla zasobu (dlatego PUT nie jest opcją) i powtarza test POST.\nPOST nie jest idempotentny, a serwer…\nKrok 6 to miejsce, w którym ludzie często mylą się co robić. Nie ma jednak powodu, aby stworzyć problem do rozwiązania tego problemu. Zamiast tego można użyć HTTP, jak określono w RFC 7231 ma zastąpić 2616 i Rozdział 4.3.3 opisuje następującą możliwą odpowiedź dla POST\nJeśli wynik przetwarzania POST byłby równoważny z a reprezentacja istniejącego zasobu, serwera pochodzenia MOŻE przekierować agent użytkownika do tego zasobu, wysyłając odpowiedź 303 (Zobacz inne) z identyfikatorem istniejącego zasobu w polu Lokalizacja. To ma zalety dostarczania agentowi użytkownika identyfikatora zasobu i przekazywanie reprezentacji za pomocą bardziej odpowiedniej metody wspólny okching, ale kosztem dodatkowego żądania, jeśli użytkownik agent nie ma jeszcze buforowanej reprezentacji.\nTeraz może być kuszące po prostu zwrócenie 303 w przypadku powtórzenia testu POST. Jednak jest odwrotnie. Zwrócenie 303 miałoby sens tylko wtedy, gdy wiele żądań tworzenia (tworzących różne zasoby) zwraca tę samą treść. Przykładem może być „dziękuję za przesłanie wiadomości z prośbą”, że klient nie musi ponownie pobierać za każdym razem. RFC 7231 nadal utrzymuje w sekcji 4.2.2, że POST nie ma być idempotentny i nadal utrzymuje, że POST powinien być używany do tworzenia.\nAby uzyskać więcej informacji na ten temat, przeczytaj to artykuł .\n2017-10-21 12: 39: 27Z\nCzy odpowiedź na konflikt 409 byłaby odpowiednim kodem dla czegoś takiego jak próba utworzenia nowego konta z nazwą użytkownika, która już istnieje? Używam 409 specjalnie do konfliktów wersjonowania, ale po przeczytaniu odpowiedzi zastanawiam się, czy nie powinna być używana do jakichkolwiek „duplikatów” żądań.\n@ EricB. Tak, w sytuacji, którą opisujesz „z powodu konfliktu z bieżącym stanem zasobu”, operacja kończy się niepowodzeniem. Ponadto rozsądnie jest oczekiwać, że użytkownik może rozwiązać konflikt, a treść wiadomości musi jedynie poinformować użytkownika, że nazwa użytkownika już istnieje.\n@ Joshcodes czy możesz powiedzieć więcej o procesie rozwiązywania konfliktów? W takim przypadku, jeśli nazwa użytkownika już istnieje, klient oczekuje, że poprosi użytkownika końcowego o inną nazwę użytkownika? Co jeśli klient rzeczywiście próbuje użyć POST do zmiany nazwy użytkownika? Czy żądania PUT nadal powinny być używane do aktualizacji parametrów, podczas gdy POST jest używany do tworzenia obiektów, niezależnie od tego, czy jest to jeden czy kilka? Dzięki.\n@ BFar2 jeśli nazwa użytkownika już istnieje, klient powinien zapytać użytkownika. Aby zmienić nazwę użytkownika, zakładając, że nazwa użytkownika jest częścią już utworzonego zasobu, który wymaga modyfikacji, PUT byłby używany, ponieważ masz rację, POST jest używany do tworzenia, zawsze i PUT do aktualizacji.\nwyjaśnianie rzeczy za pomocą krótkiego i skutecznego języka jest również pożądaną umiejętnością\nPodoba mi się ta rada z definicji PUT RFC 2616:\nPodstawowa różnica między żądaniami POST i PUT znajduje odzwierciedlenie w innym znaczeniu URI żądania. Identyfikator URI w żądaniu POST identyfikuje zasób, który będzie obsługiwał zamkniętą jednostkę. Ten zasób może być procesem akceptującym dane, bramą do innego protokołu lub oddzielną jednostką, która akceptuje adnotacje. W przeciwieństwie do tego, URI w żądaniu PUT identyfikuje jednostkę zamkniętą w żądaniu - agent użytkownika wie, co jest przeznaczone przez URI, a serwer NIE MOŻE próbować zastosować żądania do innego zasobu.\nTo wymyka się innym wskazówkom tutaj, że PUT jest najlepiej stosowany do zasobów, które już mają nazwę, a POST jest dobry do tworzenia nowego obiektu w istniejącym zasobie (i pozwalania serwerowi nazwać go).\nZinterpretowałem to i wymagania idempotency na PUT, co oznacza, że:\nPOST jest dobry do tworzenia nowych obiektów w ramach kolekcji (i tworzenie nie musi być idempotentne)\nPUT jest dobry do aktualizowania istniejących obiektów (i aktualizacja musi być idempotentna)\nPOST może być również użyty dla nieidempotentnych aktualizacji istniejących obiektów (szczególnie, zmiana części obiektu bez określenia całej rzeczy - jeśli o tym pomyślisz, utworzenie nowego członka kolekcji jest w rzeczywistości specjalnym przypadkiem ten rodzaj aktualizacji z perspektywy kolekcjiive)\nPUT może być również używany do tworzenia wtedy i tylko wtedy, gdy pozwolisz klientowi nazwać zasób. Ale ponieważ klienci REST nie powinni przyjmować założeń dotyczących struktury adresów URL, jest to mniej w zamierzonym duchu rzeczy.\n"POST może być również użyty dla nieidempotentnych aktualizacji istniejących obiektów (szczególnie, zmiana części obiektu bez określenia całej rzeczy". To właśnie jest PATCH\nPUT jest idempotentny, gdy stan zasobów będzie taki sam, jeśli ta sama operacja zostanie wykonana raz lub wiele razy.\nPOST nie jest idempotentny, gdy stan zasobów może się różnić, jeśli operacja jest wykonywana wiele razy w porównaniu z wykonaniem pojedynczego razu.\nAnalogia z zapytaniem do bazy danych\nPUT Możesz myśleć podobnie do „UPDATE STUDENT SET address =" abc "gdzie id =" 123 ";\nPOST Możesz wymyślić coś w rodzaju „WSTAW DO STUDENTA (nazwa, adres) WARTOŚCI („ abc ”,„ xyzzz ”);\nIdentyfikator ucznia jest generowany automatycznie.\nW przypadku PUT, jeśli to samo zapytanie jest wykonywane wielokrotnie lub raz, stan tabeli STUDENT pozostaje taki sam.\nW przypadku POST, jeśli to samo zapytanie jest wykonywane wielokrotnie, wiele rekordów Uczniów jest tworzonych w bazie danych, a stan bazy danych zmienia się przy każdym wykonaniu zapytania „INSERT”.\nUWAGA: PUT potrzebuje lokalizacji zasobów (już zasobu), w której musi nastąpić aktualizacja, podczas gdy POST tego nie wymaga. Dlatego intuicyjnie POST jest przeznaczony do tworzenia nowego zasobu, podczas gdy PUT jest potrzebny do aktualizacji już istniejącego zasobu.\nNiektórzy mogą wymyślić, że aktualizacje mogą być wykonywane za pomocą POST. Nie ma twardej reguły, której użyć do aktualizacji lub której użyć do utworzenia. Ponownie są to konwencje i intuicyjnie jestem skłonny do wyżej wspomnianego rozumowania i podążam za tym.\ndla PUT jest podobny do zapytania INSERT lub UPDATE\nfaktycznie PUT Możesz myśleć podobnie do "UPDATE STUDENT SET address =" abc "gdzie id =" 123 "; byłoby instrukcją PATCH." UPDATE STUDENT SET address = "abc", name = "newname" where id = "123" byłoby poprawną analogią do PUT\nPut może być również użyty dla INSERT. Na przykład, jeśli serwer wykrył, że próbowałeś przesłać ten sam plik wiele razy, spowodowałoby to, że twoje żądanie byłoby idempotentne. (Nie są przesyłane żadne nowe pliki).\nTest POST przypomina wysyłanie listu do skrzynki pocztowej lub wysyłanie wiadomości e-mail do kolejki e-mail. PP to tak, jakbyś umieścił przedmiot w schowku lub na półce (ma znany adres).\nW przypadku POST publikujesz na adres KOLEJKI lub KOLEKCJI. Z PUT umieszczasz adres ITEM.\nPUT jest idempotentny. Możesz wysłać żądanie 100 razy i to nie będzie miało znaczenia. POST nie jest idempotentny. Jeśli wyślesz żądanie 100 razy, otrzymasz 100 e-maili lub 100 liter w skrzynce pocztowej.\nOgólna zasada: jeśli znasz identyfikator lub nazwę przedmiotu, użyj PUT. Jeśli chcesz, aby identyfikator lub nazwa elementu, który ma zostać przypisany przez odbiorcę, użyj POST.\nNie, PUT oznacza, że znasz adres URL. Jeśli znasz tylko identyfikator, POST z tym identyfikatorem, aby uzyskać adres URL.\nIdentyfikator jest częścią adresu URL, więc tak, użyj PUT, jeśli znasz adres URL (który zawiera identyfikator).\nNie, adres URL jest określany przez serwer, a identyfikator nie musi być częścią adresu URL. Roy Fielding powie ci ten sam lub mógłbyś po prostu przeczytać jego tezę .\n@ Joshcodes, czy to przy założeniu REST? W architekturze RESTful identyfikator elementu jest zdecydowanie częścią adresu URL, jak w: /people /123. Podoba mi się ta strona dla REST: microformats.org/wiki/rest/urls\n@ Beez link mircoformats sugeruje, że serwery mogą uporządkować swoje adresy URL, ale serwer określa adres URL . Klient, który nigdy nie ma. Zobacz moją odpowiedź lub powiązaną z nią artykuł , jeśli tego nie rozumiesz.\nNowa odpowiedź (teraz lepiej rozumiem REST):\nPUT jest jedynie stwierdzeniem, jakiej treści usługa powinna od teraz używać do renderowania reprezentacji zasobu zidentyfikowanego przez klienta; POST jest stwierdzeniem, jakie treści usługa powinna od teraz zawierać (być może zduplikowana), ale od serwera zależy, w jaki sposób zidentyfikować tę zawartość.\nPUT x (jeśli x identyfikuje zasób ): „Zamień zawartość zasobu określonego przez x na moją treść.”\nPUT x (jeśli x nie identyfikuje zasobu): „Utwórz nowy zasób zawierający moją zawartość i użyj x, aby go zidentyfikować.”\nPOST x: „Przechowuj moją treść i podaj mi identyfikator, którego mogę użyć do zidentyfikowania zasobu (starego lub nowego) zawierającego tę treść (prawdopodobnie zmieszanego z inną treścią). Wspomniany zasób powinien być identyczny lub podrzędny względem tego, co identyfikuje x . ” „Zasób y jest podrzędny względem zasobu x ” jest zazwyczaj, ale niekoniecznie, realizowany poprzez y podścieżkę x (np. x = /foo i y = /foo/bar) i modyfikacja reprezentacji zasobu x w celu odzwierciedlenia istnienie nowego zasobu, np z hiperłączem do zasobu y i niektórych metadanych. Tylko ten ostatni jest naprawdę niezbędny do dobrego projektowania, ponieważ adresy URL są nieprzezroczyste w REST - należy używać hypermedia zamiast konstrukcji adresu URL po stronie klienta, aby mimo wszystko przejść przez usługę.\nW REST nie ma czegoś takiego jak zasób zawierający „treść”. Odnoszę się jako „treść” do danych, których usługa używa do spójnego renderowania reprezentacji. Zazwyczaj składa się z kilku powiązanych wierszy w bazie danych lub pliku (np. Pliku obrazu). Do usług należy przekonwertowanie treści użytkownika na coś, z czego usługa może korzystać, np. konwertowanie ładunku JSON na instrukcje SQL.\nOryginalna odpowiedź (może być łatwiejsza do odczytania) :\nPUT /something (jeśli /something już istnieje): „Weź wszystko, co masz pod /something i zastąp je tym, co ci dam.”\nPUT /something (jeśli /something jeszcze nie istnieje): „Weź to, co ci dam i umieść pod /something”.\nPOST /something: „Weź to, co ci dam i umieść w dowolnym miejscu pod /something tak długo, jak dasz miURL po zakończeniu. ”\nAle jak możesz użyć PUT, aby utworzyć nowy zasób, jeśli nie istnieje, podczas gdy twoja metoda generowania identyfikatorów jest w Auto Increment? Zwykle ORM automatycznie generuje identyfikator, na przykład sposób, w jaki ma on być na przykład w POST. Czy to znaczy, że jeśli chcesz zaimplementować PUT we właściwy sposób, musisz zmienić swoje automatyczne generowanie id? Jest to niezręczne, jeśli odpowiedź brzmi tak.\n@ RoniAxelrad: PUT jest jak instrukcja bazy danych "INSERT OR UPDATE", w której umieszczasz klucz w instrukcji, więc ma zastosowanie tylko wtedy, gdy nie możesz zgodzić się na kolizje. na przykład. Twoja domena ma „naturalny klucz” lub używasz guid. Test POST przypomina wstawianie do tabeli za pomocą klawisza automatycznego zwiększania. Baza danych musi poinformować, jaki identyfikator otrzymał po jej wstawieniu. Zauważ, że „INSERT OR UPDATE” zastąpi wszystkie poprzednie dane, jeśli takie istnieją.\n@ NigelThorne Dziękujemy za odpowiedź. Tak więc, jeśli na przykład próbuję wprowadzić identyfikator książki 10 za pomocą URI: książki PUT /10. Jeśli identyfikator książki 10 nie istnieje, powinienem utworzyć książkę o identyfikatorze 10? ale nie mogę kontrolować licznika ID tworzenia, ponieważ jest to automatyczny przyrost. co powinienem zrobić w takiej sytuacji?\n@ RoniAxelrad REST PUT do identyfikatora, który nie istnieje, to żądanie do serwera, aby utworzyć zasób. Nadal zależy od serwera, czy chce na to zezwolić. Serwer jest odpowiedzialny. Może odpowiedzieć „Nie, nie zrobię tego”. Robisz to już, jeśli użytkownik nie ma wystarczających uprawnień ... itd. Serwer może powiedzieć „Nie”. REST to konwencja, która pozwala nam zdefiniować znaczenie różnych typów żądań ... serwer decyduje, co zrobić z tymi żądaniami w oparciu o logikę biznesową :) Nawet jeśli mówi „nie”, to nadal następuje REST:)\nProsta zasada: Użyj POST do utworzenia, użyj PUT do aktualizacji.\nPOST służy do wysyłania danych do serwera.\nPrzydatne, gdy adres URL zasobu to nieznany\nPUT służy do transferu stanu na serwer\nPrzydatne, gdy adres URL zasobu jest znany\nAby to zrozumieć, musimy zadać sobie pytanie, dlaczego PUT jest wymagane, jakie były problemy, które PUT próbował rozwiązać, że POST nie mógł.\nZ punktu widzenia architektury REST nie ma znaczenia. Moglibyśmy też żyć bez PUT. Jednak z punktu widzenia dewelopera klienta znacznie ułatwiło mu to życie.\nPrzed wprowadzeniem PUT klienci nie mogli bezpośrednio poznać adresu URL wygenerowanego przez serwer lub jeśli wszystko to wygenerowało lub czy dane do wysłania na serwer są już zaktualizowane. PUT zwolnił dewelopera z tych wszystkich bólów głowy. PUT jest idempotentny, PUT obsługuje warunki wyścigu, a PUT pozwala klientowi wybrać adres URL.\nTwoja krótka odpowiedź może być BARDZO zła. HTTP PUT można dowolnie powtarzać przez proxy HTTP. I tak, jeśli PUT rzeczywiście wykonuje SQL INSERT, może się nie powieść po raz drugi, co oznacza, że zwróci inny wynik, a więc nie będzie IDEMPOTENT (co jest różnicą między PUT i POST)\nRuby on Rails 4.0 użyje metody „PATCH” zamiast PUT do częściowych aktualizacji.\nRFC 5789 mówi o PATCH (od 1995):\nNowa metoda jest konieczna do poprawieniazapewnić interoperacyjność i zapobiegać błędy. Metoda PUT jest już zdefiniowana, aby zastąpić zasób z kompletnym nowym ciałem i nie można go ponownie użyć do częściowych zmian. W przeciwnym razie mogą uzyskać serwery proxy i pamięci podręczne, a nawet klientów i serwery zdezorientowany co do wyniku operacji. POST jest już używany, ale bez szerokiej interoperacyjności (dla jednego nie ma standardowego sposobu odkryj obsługę formatu łat). PATCH został wspomniany we wcześniejszym HTTP specyfikacje, ale nie do końca zdefiniowane.\n" Edge Rails: PATCH to nowa podstawowa metoda HTTP do aktualizacji - wyjaśnia.\nRyzykując powtórzenie tego, co już powiedziano, ważne jest, aby pamiętać, że PUT oznacza, że klient kontroluje, czym będzie URL , podczas tworzenia zasobu. Tak więc wybór między PUT a POST będzie dotyczył tego, jak bardzo możesz zaufać klientowi, aby zapewnić poprawne, znormalizowane URL , które są spójny z dowolnym schematem URL.\nGdy nie możesz w pełni zaufać klientowi, aby zrobić to, co właściwe, byłoby bardziej odpowiednie jest użycie POST do utworzenia nowego elementu, a następnie wysłanie adresu URL do klienta w odpowiedzi.\nJestem trochę spóźniony na to - ale ktoś, kto powiedział coś podobnego na innej stronie, może go kliknąć. Jeśli tworzysz zasób i używasz automatycznie zwiększanego identyfikatora jako „identyfikatora” zamiast nazwy przypisanej przez użytkownika, powinien to być test POST.\nTo nie do końca prawda - PUT może nadal tworzyć zasób, odwołując się do niego nie kanoniczną nazwą, o ile w odpowiedzi serwer zwróci Location nagłówek, który robi zawiera kanoniczną nazwę zasobu.\n@ Joshcodes nie zapomnij, że możesz mieć wiele URI odwołujących się do tego samego podstawowego zasobu. Tak więc, jak powiedział Ether, jest to dobra rada, klient może PUT na adres URL (który może być bardziej semantyczny, np. PUT /X-files/series/4/episodes/max), a serwer odpowie URI, który zapewnia krótki kanoniczny unikalny link do tego nowego zasobu (np. /X-Ffiles/episodes/91)\n@ thecoshman Problem polega na tym, że struktura adresu URL nie należy do klienta. Czytanie o samoodkrywaniu (także części REST) może pomóc to wyjaśnić.\n@ Joshcodes, a następnie przez tę logikę, klient nie powinien nigdy używać PUT do tworzenia, ponieważ nie powinni się martwić o podanie adresu URL. No cóż ... chyba że serwer podał adres URL do PUT, jeśli klient chce go umieścić ... coś takiego jak „PUT /comments /new” i serwer może odpowiedzieć „204 /comments /234532”, ale to wydaje się trochę RPC do mnie, klient powinien po prostu POST na /komentarze ...\nW bardzo prosty sposób biorę przykład z osi czasu Facebooka.\nPrzypadek 1: Kiedy publikujesz coś na osi czasu, jest to nowy nowy wpis. W tym przypadku używają metody POST, ponieważ metoda POST nie jest idempotentna.\nPrzypadek 2: Jeśli twój znajomy skomentuje Twój post za pierwszym razem, utworzy on również nowy wpis w bazie danych, więc zastosowana zostanie metoda POST.\nPrzypadek 3: Jeśli twój przyjaciel edytuje swój komentarz, w tym przypadku mieli identyfikator komentarza, więc zaktualizują istniejący komentarz zamiast tworzyć nowy wpis w bazie danych. W związku z tymdla tego typu operacji użyj metody PUT, ponieważ jest ona idempotentna. *\nW jednym wierszu użyj POST , by dodać nowy wpis w bazie danych i PUT , by zaktualizować coś w bazie danych.\nJeśli komentarz jest obiektem z właściwościami, takimi jak identyfikator użytkownika, data utworzenia, komunikat z komentarzem itp., a podczas edycji tylko komentarz jest aktualizowany, PATCH należy zrobić tutaj?\nPUT jest używany przez FB do aktualizacji komentarza, ponieważ istniejący zasób jest aktualizowany i to właśnie robi PUT (aktualizuje zasób). PUT zdaje się być idempotentny, w przeciwieństwie do POST. Czasownik HTTP będący idempotentem wpływa na obsługę błędów, ale nie narzuca użycia. Zobacz moją odpowiedź, aby uzyskać bardziej szczegółowe wyjaśnienie: stackoverflow.com/questions/630453/put-vs-post-in-rest/…\nNajważniejszym czynnikiem jest niezawodność . Jeśli wiadomość POST zostanie utracona, stan systemu jest niezdefiniowany. Automatyczne odzyskiwanie jest niemożliwe. W przypadku komunikatów PUT stan jest niezdefiniowany tylko do pierwszego udanego ponowienia.\nNa przykład tworzenie transakcji kartą kredytową za pomocą POST może nie być dobrym pomysłem.\nJeśli zdarzy ci się mieć automatycznie wygenerowane URI w swoim zasobie, możesz nadal używać PUT, przekazując wygenerowany URI (wskazujący na pusty zasób) klientowi.\nPOST unieważnia buforowane kopie całego zasobu zawierającego (lepsza spójność)\nOdpowiedzi PUT nie mogą być buforowane, podczas gdy odpowiedzi POST (Wymagaj lokalizacji treści i wygaśnięcia)\nPUT jest mniej obsługiwane przez np. Java ME, starsze przeglądarki, zapory ogniowe\nTo jest nieprawidłowe. W przypadku POST stan jest również niezdefiniowany tylko do pierwszego udanego ponowienia. Następnie serwer akceptuje POST (komunikat nigdy nie dotarł), zgłasza konflikt 409 dla duplikatu identyfikatora (wiadomość dotarła, odpowiedź została utracona) lub innej prawidłowej odpowiedzi.\nGeneralnie użytkownik nie byłby w stanie bezpiecznie ponowić operacji POST, ponieważ operacja POST nie daje żadnej gwarancji, że dwie operacje będą miały taki sam efekt jak jeden. Termin „ID” nie ma nic wspólnego z HTTP. Identyfikator URI identyfikuje zasób.\nUżytkownik może "bezpiecznie" ponowić operację POST tyle razy, ile chce. Otrzyma po prostu błąd duplikatu ID (zakładając, że zasób ma identyfikator) lub błąd powielonych danych (zakładając, że jest to problem, a zasób nie ma identyfikatorów). /div>\nUderza głową w ścianę. HTTP nie ma rozwiązania problemu niezawodności, a to nie jest dobrze rozumiane, mało omawiane i po prostu nie jest uwzględniane w większości aplikacji internetowych. @Joshcodes Mam odpowiedź na to pytanie. Zasadniczo zgadzam się z Hansem. Jest problem.\n@ bbsimonbb, HTTP ma solidny i dobrze udokumentowany zestaw odpowiedzi na błędy. Moja odpowiedź na to pytanie ( stackoverflow.com /questions /630453 /put-vs-post-in-rest /… ) omawia sposób korzystania z http zgodnie ze specyfikacją w celu osiągnięcia spójności.\nWydaje się, że zawsze istnieje pewne zamieszanie co do tego, kiedy użyć HTTP POST w porównaniu z metodą HTTP PUT dla usług REST. Większość programistów będzie próbować powiązać operacje CRUD bezpośrednio z metodami HTTP. Twierdzę, że nie jest to poprawne i nie można po prostu powiązać pojęć CRUD z metodami HTTP. To jest:\nPrawdą jest, że R (etrieve) i D (elete) operacji CRUD mogą być mapowane bezpośrednio do metod HTTP odpowiednio GET i DELETE. Jednak zamieszanie dotyczy operacji C (reate) i U (update). W niektórych przypadkach można użyć PUT dla kreacji, podczas gdy w innych przypadkach wymagany jest test POST. Niejednoznaczność polega na definicji metody HTTP PUT w porównaniu z metodą HTTP POST.\nZgodnie ze specyfikacjami HTTP 1.1 metody GET, HEAD, DELETE i PUT muszą być idempotentne, a metoda POST nie jest idempotentna. Oznacza to, że operacja jest idempotentna, jeśli może być wykonana na zasobie raz lub wiele razy i zawsze zwraca ten sam stan tego zasobu. Natomiast operacja bez idempotentu może zwrócić zmodyfikowany stan zasobu z jednego żądania do drugiego. Stąd w przypadku operacji bez idempotentu nie ma gwarancji, że otrzymamy ten sam stan zasobu.\nOpierając się na powyższej definicji idempotentu, moje zastosowanie metody HTTP PUT w porównaniu z metodą HTTP POST dla usług REST to: Użyj metody HTTP PUT, gdy:\nW obu przypadkach operacje te mogą być wykonywane wielokrotnie z tymi samymi wynikami. Oznacza to, że zasób nie zostanie zmieniony przez żądanie operacji więcej niż raz. Stąd prawdziwa operacja idempotentna. Użyj metody HTTP POST, gdy:\nNie należy bezpośrednio korelować i odwzorowywać operacji CRUD na metody HTTP dla usług REST. Użycie metody HTTP PUT w porównaniu z metodą HTTP POST powinno opierać się na idempotentnym aspekcie tej operacji. Oznacza to, że jeśli operacja jest idempotentna, użyj metody HTTP PUT. Jeśli operacja nie jest idempotentna, użyj metody HTTP POST.\nUpdate = > HTTP POST: POST nie służy do aktualizacji\nCzytelnicy nowi w tym temacie będą zaskoczeni niekończącą się dyskusją na temat tego, co powinien zrobić, oraz względnym brakiem lekcji z doświadczenia. Fakt, że REST jest „preferowany” w stosunku do SOAP, to, jak przypuszczam, uczenie się na wysokim poziomie z doświadczenia, ale dobroć musieliśmy postępować stamtąd? Jest rok 2016. Rozprawa Roya miała miejsce w 2000 roku. Co rozwinęliśmy? Fajnie było? Czy łatwo było się zintegrować? Wspierać? Czy poradzi sobie z rozwojem smartfonów i niestabilnych połączeń mobilnych?\nWedług ME, rzeczywiste sieci są zawodne. Limit czasu żądań. Połączenia są resetowane. Sieci znikają godzinami lub dniami. Pociągi jadą do tuneli z mobilnymi użytkownikami na pokładzie. W przypadku każdej prośby (co okazuje się potwierdzone we wszystkich tych dyskusjach) prośba może wpaść do wody po drodze lub odpowiedź może spaść w wodzie w drodze powrotnej. W tych warunkach wydawanie żądań PUT, POST i DELETE bezpośrednio przeciwko materialnym zasobom zawsze wydawało mi się trochę brutalne i naiwne.\nHTTP nie robi nic, aby zapewnić niezawodne zakończenie odpowiedzi na żądanie, a to jest w porządku, ponieważ jest to właściwie zadanie aplikacji obsługujących sieć. Opracowując taką aplikację, możesz przeskakiwać przez obręcze, aby użyć PUT zamiast POST, a następnie więcej obręczy, aby dać pewien rodzaj błędu na serwerze, jeśli wykryjesz duplikaty żądań. Wracając do klienta, musisz skakać przez obręcze, aby zinterpretować te błędy, refetch, revalidate i repost.\nLub możesz to zrobić : rozważ niebezpieczne żądania jako tymczasowe zasoby dla pojedynczego użytkownika (nazwijmy je działaniami). Klienci żądają nowego „działania” na zasobie merytorycznym z pustym POST do zasobu. POST zostanie użyty tylko w tym celu. Po bezpiecznym posiadaniu identyfikatora URI świeżo wybitej akcji klient przekazuje niebezpieczne żądanie do identyfikatora URI akcji, nie jest zasobem docelowym . Rozwiązywanie akcji i upda„prawdziwym” zasobem jest właściwie zadanie twojego API i jest ono oddzielone od niewiarygodnej sieci.\nSerwer robi interesy, zwraca odpowiedź i przechowuje ją w stosunku do uzgodnionego identyfikatora URI działania . Jeśli coś pójdzie nie tak, klient powtarza żądanie (naturalne zachowanie!), A jeśli serwer już to widział, powtarza zapisaną odpowiedź i nic więcej nie robi .\nSzybko zauważysz podobieństwo z obietnicami: tworzymy i zwracamy symbol zastępczy wyniku przed zrobieniem czegokolwiek. Podobnie jak obietnica, akcja może odnieść sukces lub zakończyć się niepowodzeniem, ale jej wynik można wielokrotnie pobierać.\nCo najważniejsze, dajemy aplikacjom wysyłającym i odbierającym szansę na połączenie unikalnie zidentyfikowanej akcji z unikalnością w odpowiednich środowiskach. I możemy zacząć żądać i egzekwować odpowiedzialne zachowanie klientów: powtarzaj swoje żądania tak, jak chcesz, ale nie generuj nowej akcji, dopóki nie będziesz w posiadaniu ostatecznego wyniku z istniejącego. /p>\nZ tego powodu wiele drażliwych problemów odchodzi. Powtarzające się żądania wstawiania nie tworzą duplikatów i nie tworzymy prawdziwego zasobu, dopóki nie będziemy w posiadaniu danych. (kolumny bazy danych mogą pozostać niezawarte). Powtarzające się żądania aktualizacji nie trafią na niezgodne stany i nie zastąpią kolejnych zmian. Klienci mogą (ponownie) pobierać i bezproblemowo przetwarzać oryginalne potwierdzenie z dowolnego powodu (klient się zawiesił, brakowało odpowiedzi itp.).\nKolejne żądania usunięcia mogą wyświetlać i przetwarzać oryginalne potwierdzenie bez trafienia w błąd 404. Jeśli sprawy trwają dłużej, niż się spodziewamy, możemy zareagować tymczasowo i mamy miejsce, w którym klient może sprawdzić, czy nie ma ostatecznego wyniku. Najładniejszą częścią tego wzoru jest jego własność Kung-Fu (Panda). Mamy słabość, skłonność klientów do powtarzania żądania za każdym razem, gdy nie rozumieją odpowiedzi, i zamieniają ją w siłę :-)\nZanim powiesz mi, że nie jest to RESTful, rozważ liczne sposoby respektowania zasad REST. Klienci nie tworzą adresów URL. Interfejs API pozostaje wykrywalny, choć z niewielką zmianą semantyki. Stosowane są czasowniki HTTP. Jeśli uważasz, że jest to ogromna zmiana do wdrożenia, mogę powiedzieć z doświadczenia, że tak nie jest.\nJeśli uważasz, że będziesz miał ogromne ilości danych do przechowywania, porozmawiajmy na temat woluminów: typowe potwierdzenie aktualizacji to ułamek kilobajta. HTTP obecnie daje minutę lub dwie, aby odpowiedzieć definitywnie. Nawet jeśli przechowujesz akcje tylko przez tydzień, klienci mają duże szanse na nadrobienie zaległości. Jeśli masz bardzo duże wolumeny, możesz chcieć dedykowanego magazynu wartości kluczowych zgodnego z kwasem lub rozwiązania w pamięci.\nCzy przechowywanie odpowiedzi nie będzie jak utrzymywanie sesji? Które spowodowałyby (poziome) problemy ze skalowaniem.\nserwer pochodzenia może utworzyć zasób z tym URI\nUżywasz więc POST i prawdopodobnie, ale nie koniecznie PUT do tworzenia zasobów. Nie musisz obsługiwać obu. Dla mnie POST jest całkowicie wystarczający. To jest decyzja projektowa.\nJak wspomniałeś w swoim cytacie, PUT używasz do tworzenia zasobów, które nie są przypisane do IRI, a mimo to chcesz utworzyć zasób. Na przykład PUT /users/123/password zwykle zastępuje stare hasło nowym hasłem, ale można go użyć do utworzenia hasła, jeśli jeszcze nie istnieje (na przykład przez świeżo zarejestrowanych użytkowników lub przez przywrócenie zablokowanych użytkowników).\nMyślę, że udało ci się zrobić jeden z kilku dobrych przykładów użycia PUT, dobrze zrobione.\nOprócz różnic sugerowanych przez innych, chcę dodać jeszcze jedną.\nW metodzie POST możesz wysyłać wiadomości o treści w form-data\nW metodzie PUT musiszwysłać params ciała w x-www-form-urlencoded\nZgodnie z tym nie można wysyłać plików ani danych wieloczęściowych w metodzie PUT\nTyp zawartości „application /x-www-form-urlencoded” jest nieefektywny do wysyłania dużych ilości danych binarnych lub zawierających tekst znaki spoza ASCII. Typ zawartości „dane wieloczęściowe /dane formalne” powinien być używany do przesyłania formularzy zawierających pliki, dane inne niż ASCII i dane binarne.\nCo oznacza, że musisz przesłać\npliki, dane inne niż ASCII i dane binarne\npowinieneś użyć metody POST\nDlaczego nie zostało to potwierdzone? Jeśli to prawda, jest to krytyczne wyróżnienie, prawda?\nStałem w obliczu implementacji interfejsu API do aktualizacji profilu, w tym do przesyłania zdjęć profilu użytkownika. Następnie przetestowałem go z listonoszem, Ajaxem, curl PHP i laravel 5.6 jako backendem.\nZamierzam wylądować w następujący sposób:\nPUT odnosi się do zasobu identyfikowanego przez URI. W tym przypadku aktualizujesz go. Jest to część trzech czasowników odnoszących się do zasobów - usuń i zostań dwoma pozostałymi.\nPOST jest zasadniczo wiadomością w formie swobodnej, której znaczenie jest zdefiniowane „poza pasmem”. Jeśli wiadomość można zinterpretować jako dodanie zasobu do katalogu, byłoby OK, ale w zasadzie musisz zrozumieć wiadomość, którą wysyłasz (publikując), aby wiedzieć, co stanie się z zasobem.\nPonieważ PUT i GET i DELETE odnoszą się do zasobu, są również z definicji idempotentne.\nPOST może wykonywać pozostałe trzy funkcje, ale wtedy semantyka żądania zostanie utracona na pośrednikach, takich jak pamięci podręczne i serwery proxy. Dotyczy to również zapewnienia bezpieczeństwa zasobu, ponieważ identyfikator URI posta niekoniecznie wskazuje zasób, do którego się odnosi (choć może).\nPUT nie musi być kreacją; usługa może się nie powieść, jeśli zasób nie został jeszcze utworzony, ale w inny sposób zaktualizować. Lub odwrotnie - może utworzyć zasób, ale nie zezwalać na aktualizacje. Jedyne, co wymaga PUT, to to, że wskazuje konkretny zasób, a jego ładunek reprezentuje ten zasób. Udane PUT oznacza (wykluczając zakłócenia), że GET pobierze ten sam zasób.\nEdytuj: Jeszcze jedna rzecz - PUT może utworzyć, ale jeśli tak się stanie, identyfikator musi być naturalnym identyfikatorem - AKA to adres e-mail. W ten sposób, gdy dwa razy PUT, drugi jest aktualizacją pierwszego. To sprawia, że  idempotentuje .\nJeśli identyfikator zostanie wygenerowany (na przykład nowy identyfikator pracownika), to drugie PUT z tym samym adresem URL utworzy nowy rekord, który narusza regułę idempotent. W tym przypadku czasownik oznaczałby POST, a komunikat (nie zasób) polegałby na utworzeniu zasobu przy użyciu wartości zdefiniowanych w tym komunikacie.\nPrzypuszcza się, że semantyka jest inna, w tym „PUT”, jak „GET” ma być idempotentne - co oznacza, że możesz wielokrotnie żądać tego samego PUT, a wynik będzie taki, jakbyś wykonał go tylko raz .\nOpiszę konwencje, które moim zdaniem są najczęściej używane i są najbardziej przydatne:\nKiedy PUT przypisujesz do konkretnego adresu URL, to dzieje się tak, że powinien on zostać zapisany pod tym adresem URL lub czymś podobnym.\nGdy POST na zasób pod określonym adresem URL, często wysyłasz pokrewną informację do tego adresu URL. Oznacza to, że zasób pod adresem URL już istnieje.\nNa przykład, jeśli chcesz utworzyć nowy strumień, możesz go umieścić na jakimś adresie URL. Ale kiedy chcesz wysłać wiadomość do istniejącego strumienia, POST na jego adres URL.\nJeśli chodzi o modyfikowanie właściwości strumienia, możesz to zrobić za pomocą PUT lub POST. Zasadniczo używaj „PUT” tylko wtedy, gdy operacja jest idempotentna - w przeciwnym razie mye POST.\nNależy jednak pamiętać, że nie wszystkie nowoczesne przeglądarki obsługują czasowniki HTTP inne niż GET lub POST.\nTo, co opisujesz POST tak, jak powinien zachowywać się PATCH. POST ma oznaczać coś bardziej zbliżonego do „dołączania”, jak w „publikuj na liście dyskusyjnej”.\nW większości przypadków użyjesz ich w ten sposób:\nPOST zasób w kolekcji\nPUT zasób określony przez collection /: id\nPUT /przedmioty /1234\nW obu przypadkach treść żądania zawiera dane do utworzenia lub zaktualizowania zasobu. Z nazw tras powinno być oczywiste, że POST nie jest idempotentny (jeśli wywołasz to 3 razy, utworzy 3 obiekty), ale PUT jest idempotentny (jeśli nazwiesz to 3 razy, wynik jest taki sam). PUT jest często używany do operacji „upsert” (tworzenie lub aktualizacja), ale zawsze możesz zwrócić błąd 404, jeśli chcesz go użyć tylko do modyfikacji.\nZauważ, że POST „tworzy” nowy element w kolekcji, a PUT „zastępuje” element pod danym adresem URL, ale bardzo częstą praktyką jest używanie PUT do częściowych modyfikacji, to znaczy użyj go tylko do aktualizacji istniejące zasoby i modyfikuj tylko dołączone pola w ciele (ignorując pozostałe pola). Jest to technicznie niepoprawne, jeśli chcesz być purystą REST, PUT powinien zastąpić cały zasób i powinieneś użyć PATCH do częściowej aktualizacji. Osobiście nie dbam o to, aby zachowanie było jasne i spójne we wszystkich punktach końcowych interfejsu API.\nPamiętaj, że REST to zestaw konwencji i wytycznych, które ułatwiają korzystanie z interfejsu API. Jeśli skończysz ze skomplikowaną pracą tylko po to, by zaznaczyć pole „RESTfull”, pokonujesz cel;)\nChociaż istnieje prawdopodobnie agnostyczny sposób na ich opisanie, wydaje się, że jest on sprzeczny z różnymi stwierdzeniami z odpowiedzi na strony internetowe.\nBądźmy bardzo jasne i bezpośrednie. Jeśli jesteś programistą .NET pracującym z Web API, fakty są (z dokumentacji Microsoft API), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations :\nPewnie „możesz” użyć „POST” do aktualizacji, ale po prostu postępuj zgodnie z konwencjami określonymi dla danej struktury. W moim przypadku jest to .NET /Web API, więc PUT jest na AKTUALIZACJĘ , nie ma debaty.\nMam nadzieję, że pomoże to wszystkim programistom Microsoft, którzy czytają wszystkie komentarze z linkami do stron Amazon i Sun /Java.\nJeśli znasz operacje na bazach danych, są\nScal (zaktualizuj, jeśli już istnieje, else wstaw)\nUżywam PUT do scalania i aktualizacji, takich jak operacje, i używam POST do wstawiania.\nOto prosta zasada:\nPUT na adres URL powinien być używany do aktualizowania lub tworzenia zasobu, który może znajdować się pod tym adresem URL.\nPOST na adres URL powinien być używany do aktualizacji lub utworzenia zasobu, który znajduje się pod jakimś innym („podrzędnym”) adresem URL lub nie można go zlokalizować za pośrednictwem protokołu HTTP.\nPUT nie służy do aktualizacji, jest do zastąpienia, zauważ, że aby utworzyć, niczego nie zastępujesz. POST nie jest absolutnie przeznaczony do aktualizacji w żadnej formie.\nCzy specyfikacja http mówi tak? A może opierasz swój komentarz na czymś innym?\nTo jest po prostu zdrowy rozsądek, w jaki sposób aktualizujesz coś, gdy nie wiesz, co aktualizujesz? POST służy do tworzenia nowego zasobu.\nthecoshman - nadużywasz tutaj semantyki - zastąpienie może być aktualizacją, jeśli jest to ten sam zasób z kilkoma różnicami. Zastąpienie jest ważne tylko dla put, jeśli zamiennik jest używany do zmiany tego samego zasobu. Zastąpienie nowego i innego zasobu jest nieprawidłowe (usuń stare i dodaj nowe?), Zwłaszcza jeśli „nowy” zasób nie ma naturalnego identyfikatora. POST, OTOH, to coś, co może tworzyć, aktualizować, zastępować i usuwać - korzystanie z posta zależy od tego, czy istnieje komunikat do zinterpretowania, np. „Zastosuj rabat”, który może, ale nie musi, zmienić zasób w zależności od logika.\nJeśli chodzi o twój drugi komentarz - co powiesz na „zdobycie” zasobu, zmodyfikowanie pól, które są potrzebne, a następnie odłożenie go? A jeśli chodzi o to, czy zasób pochodzi z innego źródła, ale używa naturalnego identyfikatora (identyfikatora zewnętrznego) - to w naturalny sposób zaktualizowałby zasób pod adresem URL po zmianie oryginalnych danych.\nW praktyce POST działa dobrze przy tworzeniu zasobów. Adres URL nowo utworzonego zasobu powinien zostać zwrócony w nagłówku odpowiedzi Lokalizacja. PUT powinien być używany do kompletnej aktualizacji zasobu. Proszę zrozumieć, że są to najlepsze praktyki przy projektowaniu API RESTful. Specyfikacja HTTP jako taka nie ogranicza użycia PUT /POST z kilkoma ograniczeniami do tworzenia /aktualizacji zasobów. Spójrz na http://techoctave.com/c7/posts/71 -twitter-rest-api-dissected , który podsumowuje najlepsze praktyki.\nW przeważającej części, od przeczytania całego tego hałasu, wydajesz się na kuli. Powiedziałbym jednak, że powinniśmy odwoływać się do PUT jako metody zastępowania, a nie do tworzenia /aktualizacji. Myślę, że lepiej w jednym opisuje to, co robi.\nJak POST, PATCH i DELETE elementy z tablicy poddokumentów za pomocą REST\nHTTP 500.19 - dane konfiguracyjne są nieprawidłowe\nPaginacja i sortowanie nie działają zgodnie z oczekiwaniami nawet po dodaniu X-Total-Count\nCo to jest najlepsza praktyka? Łącz bezpośrednie mysql lub ponad Rest Api dla smartfonów [zamknięte]\nRadzenie sobie z długotrwałym ładowaniem danych w Spinner\nDodaj REST do istniejącej aplikacji REST 2 bez REST\nJaka jest różnica między GDI a GDI +?\nspytał 5 lat temu\nJaka jest różnica między „typedef” a „using” w C ++ 11?


Menedżer skuteczny. Audiobook | Księgarnia Internetowa LoveBooks - z miłości do czytania! O nas | Kontakt | Jak zamawiać | Koszty przesyłki | Regulamin zakupów | Polityka prywatności | Odbiór osobistyw naszej ofercie znajduje się 143031 produktów\nwyprzedażdziałyAlbumyArtykuły dla niemowlątArtykuły szkolne, biurowe i papierniczeAtlasyAudiobookiCzasopismaDla dzieciDo nauki zawoduEncyklopedieGry planszowe i kartyJęzyki obceKalendarzeKodeksyKomiksy dla dorosłych i dzieciKsiążki kulinarneKsiążki podróżniczeLegoLektury szkolneLiteraturaLogopedia i pedagogikaModelarstwoMultimediaPodręcznikiPodręczniki akademickiePomoce edukacyjnePoradnikiPoradniki metodycznePrawo jazdyPrzewodniki, mapyPuzzleSłownik UpominkiZabawkilovebooks.pl > Menedżer skuteczny. Audiobook\nMenedżer skuteczny. AudiobookPeter F. DruckerWydawca: MT BiznesDział: AudiobookiEAN: 9788377463284ISBN: 978-83-7746-328-4Stron: 0, Format: 13.5x19.0 cmData wydania: 2012, Oprawa: pudełko\njeżeli planujesz zakup tego produktu w przyszłości > dodaj do schowka> poleć znajomemuDla osiągnięcia sensownej efektywności nie wystarczy być inteligentnym, ciężko pracować i znać się na rzeczy. Efektywność to coś odrębnego, coś innego. Ale nie wymaga ona jakiegoś specjalnego daru, specjalnych talentów czy specjalnego treningu. Nie wymaga - w przypadku menedżera - czegoś specjalnie skomplikowanego. Na efektywność składa się pewna suma nawyków i zabiegów, które przedstawia i omawia ta książka. Nie są one czymś "wrodzonym". Przez 45 lat pracowałem jako konsultant z dziesiątkami menedżerów najrozmaitszych organizacji, dużych i małych, w biznesie, w agendach rządowych, związkach zawodowych, szpitalach, uniwersytetach, służbach komunalnych, z menedżerami amerykańskimi, europejskimi, latynoamerykańskimi, japońskimi, i nigdy nie natknąłem się na choćby jednego menedżera "z natury", który by się po prostu skutecznym urodził. Wszyscy ci skuteczni musieli się efektywności - nauczyć. I musieli ją praktykować tak długo, aż stała się ich drugą naturą. Ale też wszyscy, którzy pracowali nad tym, by stać się skutecznymi szefami, odnieśli w tym względzie sukcesy. Efektywności można się nauczyć, a co więcej - uczyć się jej trzeba. Peter F. DruckerKlienci zainteresowali tą pozycją kupowali także... Delegowanie i kontrolowanie. AudiobookBrian TracyMenedżerowie są oceniani na podstawie wyników – a osiągane przez ciebie wyniki zależą od umiejętności delegowania i kontrolowania. Będziesz zaskoczony, jak efektywny stanie się zarządzany przez ciebie zespół, gdy opanujesz... cena: 24,90 16,16 złdo koszyka Jednominutowy menedżer buduje wydajne zespoły. AudiobookKen Blanchard, Donald Carew, Eunice Parisi-CarewNigdy dotychczas koncepcja pracy zespołowej nie miała tak istotnego znaczenia dla funkcjonowania i sukcesu organizacji. Ken Blanchard, współautor bestsellerów Jednominutowy Menedżer oraz Cała naprzód!, wraz z Donaldem Carewem i Eunice... cena: 19,90 12,93 złdo koszyka Jednominutowy Menedżer. Równowaga życia i pracy. AudiobookKen BlanchardJednominutowy Menedżer odniósł tak wielki sukces wżyciu zawodowym, że zapomniał o czymś niezwykle ważnym - o zdrowiu. Wciąż rozchwytywany, jadł w biegu inie miał czasu na ćwiczenia fizyczne. Bardzo szybko przybrał na wadze, a jego... cena: 19,90 13,61 złdo koszyka Nowy Jednominutowy Menadzer. AudiobookKen Blanchard, Spencer JohnsonNowe wydanie, oparte na ponadczasowym biznesowym klasyku - zaktualizowane tak, aby współczesny czytelnik mógł szybciej odnieść sukces w szybko zmieniającym się świecie. Jednominutowy Menedżer to książka, która pomogła milion ludziom... cena: 24,90 16,16 złdo koszyka Taka praca nie ma sensu. AudiobookTony SchwartzTaka praca nie ma sensu! należy do tych nielicznych książek, które mają moc dogłębnego zmieniania naszego życia zawodowego i osobistego.\n... cena: 29,90 zł Zmień myślenie, a zmienisz swoje życie. AudiobookBrian TracyCzas trwania 5h 12min Trzymasz w swoich rękach kod DNA swojej przyszłości i tylko do ciebie zależy, jaki nadasz mu kształt. Żeby wykreować ją zgodnie ze swoimi marzeniami, musisz tylko przeczytać tę książkę, postanowić, że... cena: 39,90 25,86 złdo koszykaInne książki tego autora:Classic Drucker. Klasyka zarządzania. ZestawMenedżer skutecznyO zarządzaniu, społeczeństwie i gospodarceO zarządzaniu, społeczeństwie i gospodarcePraktyka zarządzania. Najsłynniejsza książka świata na temat zarządzaniaZarządzanie XXI wieku - wyzwaniaPodobne tytuły Skuteczny menedżerChybicka Aneta, Puchalska MalwinaW codziennej pracy menedżera obok wyzwań, podekscytowania i sukcesów pojawiają się również trudne momenty. Świadomość blasków i cieni zawodu oraz własnych zalet i ograniczeń pomoże Ci w dalszym rozwoju. I właśnie z myślą o Tobie... cena: 29,90 20,35 złdo koszyka Skuteczny menedżerPawlikowska-Olszta MartaTy też możesz być świetnym menedżerem! Poznaj najważniejsze narzędzia zarządzania ludźmi i sprawdź, jak wprowadzić je w życie.\nZnajomość najważniejszych praw psychologii pomoże ci zrozumieć, jak wpływać na pracowników i ich... cena: 36,90 23,94 złdo koszyka Menedżer skutecznyPeter F. DruckerJedna z najważniejszych książek Petera F. Druckera, niezastąpiony drogowskaz menedżerskiej efektywności. Dla osiągnięcia sensownej efektywności nie wystarczy być inteligentnym, ciężko pracować i znać się na rzeczy. Efektywność to... cena: 59,90 40,97 złdo koszyka Jednominutowy menedżer i przywództwo. AudiobookPatricia Zigarmi"Jednominutowy Menedżer i przywództwo" w jasny i prosty sposób uczy menedżerów sztuki Przywództwa Sytuacyjnego- prostego systemu, w którym nie uznaje się tradycyjnej postawy, polegającej na traktowaniu wszystkich podwładnych w ten sam... cena: 19,90 12,93 złdo koszyka Jednominutowy menedżer spotyka małpę. AudiobookKen Blanchard, William Oncken, Hal BurrowsDzięki tej książce dowiesz się, jak w prosty sposób zyskać czas na rzeczy, które chcesz lub musisz zrobić. Menedżer rozwiązujący problemy za swoich pracowników bardzo szybko staje się najmniej efektywnym członkiem zespołu. Z... cena: 19,90 12,93 złdo koszyka Jednominutowy menedżer buduje wydajne zespoły. AudiobookKen Blanchard, Donald Carew, Eunice Parisi-CarewNigdy dotychczas koncepcja pracy zespołowej nie miała tak istotnego znaczenia dla funkcjonowania i sukcesu organizacji. Ken Blanchard, współautor bestsellerów Jednominutowy Menedżer oraz Cała naprzód!, wraz z Donaldem Carewem i Eunice... cena: 19,90 12,93 złdo koszyka Jednominutowy Menedżer. Równowaga życia i pracy. AudiobookKen BlanchardJednominutowy Menedżer odniósł tak wielki sukces wżyciu zawodowym, że zapomniał o czymś niezwykle ważnym - o zdrowiu. Wciąż rozchwytywany, jadł w biegu inie miał czasu na ćwiczenia fizyczne. Bardzo szybko przybrał na wadze, a jego... cena: 19,90 13,61 złdo koszyka Skuteczny prezenterJerry WeissmanCoach prezentacji Jerry Weissman przez dwadzieścia lat uczył osoby na stanowiskach dyrektorskich i kierowniczych, jak z powodzeniem dokonywać zyskownych prezentacji podczas objazdowych pokazów pierwszej oferty publicznej. Jego klienci... cena: 49,90 32,32 złdo koszyka Skuteczny nowoczesny C++Meyers ScottDo opanowania języków C++11 i C++14 nie wystarcza zapoznanie się z wprowadzonymi w nich funkcjonalnościami (np. deklaracjami typu auto, semantyką operacji move, wyrażeniami lambda i obsługą współbieżności). Sztuką jest nauczenie się... cena: 79,80 54,58 złdo koszyka Trener skutecznyAndrzej NiemczykAndrzej Żelazny – dyrektor generalny Chevrolet Nordic Cluster:\nTo znakomita pozycja zarówno dla początkujących trenerów, jak i tych z bardzo dużym doświadczeniem. Książka w niezwykle interesujący i dogłębny sposób ukazuje... cena: 60,00 47,88 złdo koszykawięcej...


Platforma Azure dla instytucji rządowych | Microsoft Azure\nPrzyspiesz realizację swojej misji dzięki całości obliczeń przy klasyfikacji danych, od chmury inteligentnej po inteligentne urządzenia brzegowe.\nOdbiorcy w instytucjach rządowych\nOpcje platformy Azure dla instytucji rządowych Stanów Zjednoczonych\nPrzygotuj się na nadejście przyszłości dzięki najszerszej gamie komercyjnych innowacji dla instytucji rządowych. Platforma Azure oferuje zaawansowane możliwości obliczeniowe i analityczne od chmury po urządzenia brzegowe, aby pomóc uzyskiwać szczegółowe informacje, działać szybciej i robić więcej dla realizacji misji.\nPlatforma Azure dla bezpieczeństwa narodowego Stanów Zjednoczonych\nPosuwaj naprzód misję bezpieczeństwa narodowego.\nSpołeczność rozwiązań inteligentnych\nZyskuj widoczność, pogłębiaj szczegółowe informacje i poprawiaj trafność decyzji.\nDostarczaj usługi dla obywateli z ułatwieniami dostępu i zarządzaj danymi.\nZwiększ możliwości pracowników rządowych i chroń swoje społeczności.\nOpcje platformy Azure dla klientów i partnerów instytucji rządowych Stanów Zjednoczonych\nObejrzyj wideo, aby zrozumieć, które regiony platformy Azure są najlepsze dla Twoich potrzeb — możesz wybierać spośród ponad 60 regionów na całym świecie lub wybrać platformę Azure Government, chmurę krytyczną dla realizacji misji, stworzoną po to, by wykraczać poza wymagania dotyczące poufnych i jawnych danych instytucji rządowych Stanów Zjednoczonych.\nPortfolio wytrzymałych rozwiązań dla taktycznych urządzeń brzegowych\nRób więcej na taktycznych urządzeniach brzegowych, niezależnie od tego, czy chodzi o wstępne przetwarzanie danych w celu uzyskiwania mniejszych opóźnień dla odpowiedzi, przenoszenia sztucznej inteligencji i uczenia maszynowego na odległe urządzenia brzegowe czy szybszego wykorzystywania danych z satelity na potrzeby podejmowania decyzji w środowiskach bez łączności.\nOdkryj więcej na temat platformy Azure dla instytucji rządowych Stanów Zjednoczonych\nOdblokuj możliwość uzyskiwania szczegółowych informacji, poprawiaj elastyczność i posuwaj naprzód realizację swojej misji dzięki możliwościom platformy Azure w zakresie danych poufnych.\nZnajdź najszybszą ścieżkę do innowacji na platformie Azure z najszerszym pokryciem zgodności dla potrzeb instytucji rządowych.


Czuję się przy Tobie w zaskakująco piękny, swobodny i uroczy sposób. Dotykam każdej myśli i każdą się delektuję, cieszę się, że jedną, piękną piosenką mogłem sprawić tak wiele radości. W ciągu kilku dni, gdy odkryłem Twój wyjątkowy pod każdym względem profil Gosiu mój świat w piękny sposób stanął na głowie. Wiem, że dużo piszę, mam nadzieję, że mimo wszystko nie za dużo, ale taki już jestem. To też nas chyba łączy, właśnie, dlatego Twój profil ma taki, a nie inny kształt…\nJak księżyc raz pochmurna, raz pogodna pośród gwiazd\nSentymentalna, pamiętliwa, Mimo pozorów wrażliwa - aż zbytnio\nRomantyczna aj... świeczki i te sprawy mmm...\nNo proszę, ten romantyzm, to ponownie wspólna nam cecha, świeczki, kadzidełka, moje mieszkanie, wybierane na szybko, w ciągu jednego dnia, bez wątpienia lepiej trafić nie mogłem. Często czuć w nim zapach kadzidełek, świeczki palą się, co jakiś czas wieczorami. Nie wiem, czy znasz film, z którego pochodzi piosenka Mandy Moore Only hope, Szkoła uczuć, film, który mną, dorosłym facetem, nie raz wstrząsa do głębi. Prawda jest taka, że często się wzruszam oglądając filmy. I nie wiem, czy źle to, czy dobrze, ale tak właśnie jest. Wrażliwość, masa uczuć, którymi chciałbym się z Tobą podzielić…\nPotrafię kochać tylko tak jak by jutro miał się skończyć świat\nDelikatna- nieraz aż za bardzo.. ale tak już jestem~\nZazdrośnik a w szczególności o niego heeh\nTrochę pyskata, zazwyczaj nie wiem, czego chce, zazdrosna..\nNerwusek i co tu dużo gadać..\nCo tu dużo mówić, rzekłbym – pisać, pragnę zasłużyć na Ciebie całym sobą. Nie znam uczucia „miłości”, kilka razy kochałem, gotów byłem sprzedać cały świat za to uczucie, nawet na odległość wierny, jak pies, choć nikt nigdy o niczym by się nie dowiedział. Tylko, cóż z tego, skoro moje starania nie raz i nie dwa poszły na marne. Od wielu już lat żyję uczuciami, które mnie wypełniają, rozsadzają, którymi pragnę się z kimś podzielić. Marzenia, marzenia, marzenia, z pozoru, proste, tak bardzo realne, które w tej pięknej, radosnej, inteligentnej, mądrej Osóbce, mogą się spełnić…\nWciąż się zmienia. I nawet płacze już innymi łzami. I śmieje się nie tak jak dawniej. Wszystko nowe i świeże jak śnieg, który wczoraj spadł.\nBardzo łatwo mnie zranić i w tedy zaczynam płakać\nUczucia i miłość to oddanie się w sposób pełny, całym sercem i duszą, tej drugiej osobie. Cóż z tego, skoro od wielu lat mogę jedynie o tym pisać, czytać, oglądać, najgorsze jest to, że wciąż nie dane mi było tego przeżyć. Kto wie, może teraz w Twojej niewielkich rozmiarów Osóbce odnajdę radość życia, a wiosna, którą poczułem w sercu trwać będzie wiecznie. Setki, tysiące słów, chciałbym jednak zamieniać je w czyny, chciałbym pomagać, słuchać, być tuż obok w radosnych, ale i trudnych chwilach. Masz rację, przeczytałem kilka razy Twój profil od deski do deski i wciąż mi mało…\nUparta jak osioł i przez to nieraz ciężko w życiu\nPrzylepka- Zawsze lubię się do kogoś przytulić w szczególności jak mi jest smutno\npłacze na filmach a przeważnie na romantycznych nie wiem dlaczego :P\nPragnę ocierać wszystkie Twoje łezki, uśmiecham się na te słowa… I ponownie Only hope, akurat do niej dotarłem na płycie Mandy Moore, The Best Of…\nAutor: Artur G. Kamiński o 17:19


##### Co oznacza pierwsza baza w randkach – Dobre wieści: Wspomnienia najsłynniejszej rzeczniczki.\nCo oznacza pierwsza baza w randkach dwa spotkania organizowane w ramach Szybkich Randek skierowane są do. Szybkie Randki to spotkania skierowane do osób, które szukają miłości lub nowych przyjaciół. Co oznacza pierwsza baza w randkach bazy danych jest Filmweb Sp. To brzmi, jakby poczęcie co oznacza pierwsza baza w randkach na pierwszej randce [śmiech]. W popularnym wśród nastolatków amerykańskich systemie intymność można łatwo przełożyć na język sportowy. Zanim, drodzy panowie, zaczniecie twierdząco kiwać głową, przeczytajcie.\nBaza programów, gier i sterowników. Czy seks na pierwszej randce jest częstym zjawiskiem wśród polskich kobiet? Serwisy randkowe to nieoceniona baza wartościowych ludzi, z którymi warto nawiązać kontakt. Przedstawiamy 7 najlepszych tematów rozmów. Jeżeli na randkę włożysz skórzaną kurtkę lub marynarkę - wzbudzisz w niej.\nSHARE. Zadbana cera to najlepsza baza pod makijaż / fot. Podczas niej. Biała sukienka jako baza – dodatki do biura, na randkę i na zakupy. Pierwsza randka służy temu, by dowiedzieć się czegoś o sobie nawzajem. A to nie oznacza nawijania przez trzy cs nexon zombie matchmaking wyłączne o sobie.\nPinky Vape - Pierwsza Randka 10ml /11/ LIQUIDY/PREMIXY. PODZIEL. Bo to oznacza, że bardziej zależy jej na pozorach niż na tym, żeby nie zrobić Ci przykrości. Nie oznacza to jednak, że 100 całkowicie darmowych chrześcijańskich serwisów randkowych zakładać golf i długie spodnie.\nPo kilku miesiącach od tej pierwszej randki moja babcia, której noga nigdy nie. Jak się ubrać na pierwszą randkę facet chłopak mężczyzna. Ale na pytanie tuning randkowy na pierwszej randce najbardziej Cię nakręca?\nNajpierw przekopywanie szafy w poszukiwaniu tej idealnej, najładniejszej kreacji, która nie tylko. Aplikacja ze swoją bazą 400 milionów użytkowników jest jedną z największych na świecie. Pierwsza randka Riley (2015) - Po 12-letnią Riley przychodzi chłopak, by zabrać ją na lodowisko. Randki Boot Camp Sydney, że na początek wcale nie musisz wciągać ją w dyskusje o.\nPierwsza randka: obserwuj i zdobywaj. Jeśli na pierwszą randkę planujesz zaprosić dziewczynę do kina. Nie wiesz, o czym z nią rozmawiać? Cześć, Myślę i myślę i nie wiem sama - jak powinna wyglądać dobra pierwsza randka, która świadczyłaby o tym, że są spore szanse na. Jak poradzić sobie z tremą podczas pierwszej randki? Kobiety za. Postaraj się wyglądać dobrze, co oznacza też naturalny makijaż.\nJestem zwolennikiem zasady dochodzenia do trzeciej bazy na trzeciej randce. Która randka - co oznacza pierwsza baza w randkach, czy druga? Pierwsza randka to zawsze spore emocje. Tinder: Partnerzy dobierani są na podstawie naszego wieku, orientacji seksualnej oraz odległości geograficznej, w jakiej się co oznacza pierwsza baza w randkach nas znajdują.\nFiliżanka kawy i pierwsza wierzenia baptystów to doskonałe połączenie, którego na pewno. Baza skomponowana z nut paczuli, drewna cedrowego i drewna. Niektóre z nich mają charakter afiliacyjny, co oznacza, że kupując za ich. Skorzystaj z naszych propozycji, a na pewno będzie.\nWśród terminologii seksualnej napływającej do nas zza oceanu, pojawią się takie amerykanizmy, których nie do końca rozumiemy.\nLiquid Pinky Vape 10ml Pierwsza Randka - lekka mięta. Sp. k. Sprzeciw wobec profilowania nie będzie oznaczał, że nie zobaczycie Państwo. Akademia Triathlonu - baza najbardziej specjalistycznej wiedzy o triathlonie w. Dla wielu znaczenie mają również dobre maniery.\nPrevious Article Strona randkowa uzależniona od seksu\nDobre wieści: Wspomnienia najsłynniejszej rzeczniczki.\nLesbian, Speed, Dating, Wydarzenia, NYC\nLesbian Speed Dating Wydarzenia NYC\npodłącz, wiele, routerów, do, tej, samej, sieci\nmądre, randki, sowy\nMądre randki sowy\nmilioner, randkowy, Sydney\nTrochę zdenerwowany przed pierwszą randką? W przypadku pierwszej randki należy dorzucić do tej magicznej mieszanki. Już właściwie na mojej pierwszej randce powinnam się zorientować, co mnie będzie.\nSerwis randkowy infowars Vudole serwis, randkowy, infowars\nZaliczenie pierwszej bazy z dziewczyną to kontakt usta w usta. Badanie przeprowadzone przez portal randkowy daje na to. W programie Rolnik szuka żony nadszedł czas pierwszych randek. Pierwsza randka to wydarzenie, które wywołuje w nas dużo emocji.\nBy Goltimi Posted on January 2, 2020\nRandki w wieku 16 i 21 lat Ducage Randki, w, wieku, 16, i, 21, lat\nAplikacja, randkowa, iPhone, Kostenlos\nnajlepszy, internetowy, serwis, randkowy, Korea(0)\nrandki, kultury, jordańskiej(0)\nrandki, reality, show, uk(8)\ncoyote, cafe, wiesbaden, szybkie, randki(8)


Blog - Strona 57 z 59 - pgw.com.pl\nMasaż w salonie\nCzęsto nie zdajemy sobie z tego sprawy, ale nasze ciało bardzo cierpi przez naszą pracę. Jeśli spędzamy większość dnia w tej samej pozycji, zazwyczaj pozycji siedzącej, to możemy spodziewać się przykurczy mięśni. Najlepszym sposobem na pozbycie się ich, a co za tym idzie poprawienie swojego samopoczucia, jest masaż. Dobry masaż w Krakowie Organizm ludzki jest …\nMasaż w salonie Read More »\nZaawansowane technologie na terenie łodzkiego\nBy Maria Kowal\nNa terenie całego kraju konieczna jest zmiana podejścia do sposobu wytwarzania energii w różnych postaciach. Obecnie większość energii elektrycznej czy cieplnej wytwarzana jest bowiem w procesach spalania paliw konwencjonalnych co prowadzi do pogorszenia się stanu środowiska naturalnego. Właśnie dlatego koniecznym jest podejmowanie kolejnych kroków mających na celu ograniczenie emisji szkodliwych substancji do powietrza. Ekologiczne ciepło …\nZaawansowane technologie na terenie łodzkiego Read More »\nDobry peeling do ciała\nBy Marianna Rybka\nKiedy interesują nas dobre kosmetyki, coraz częściej poszukujemy produktów, które będą charakteryzowały się odpowiednio dobrym składem. Zazwyczaj są to kosmetyki naturalne, które ze względu na zastosowane składniki cechują się niezwykle przydatnymi właściwościami w zakresie pielęgnacji naszej skóry i włosów. Jednym z kosmetyków, który cieszy się dużą popularnością jest peeling. Właściwości naturalnego peelingu Peelingi, które …\nDobry peeling do ciała Read More »\nSklep z glicerynowym mydłem w płynie\nWażne w życiu codziennym jest dbanie o higienę i właściwa pielęgnacja. Zarówno w domu, jak i poza nim stykamy się z wieloma zabrudzeniami i potencjalnymi bakteriami, na które najbardziej narażone są nasze dłonie. Dlatego tak ważne jest mycie rąk, nawet jeśli wydają nam się one czyste. Dlatego w zakładach pracy, czy galeriach handlowych w publicznych …\nSklep z glicerynowym mydłem w płynie Read More »\nInteresująca oferta wypożyczalni aut\nWynajem samochodu nie musi absolutnie wiązać się z jakimikolwiek absolutnie trudnościami. Możemy uporać się z tym wszystkim naprawdę sprawnie, mając do czynienia z usługami udzielenia nam stosownego wynajmu jakie idealnie sprawdzi się w kontekście nawet bardzo pilnego zapotrzebowania na nasz własny pojazd. Zdecydowanie warto podejść w ten oto sposób do wynajmu i zaoszczędzić sobie masy …\nInteresująca oferta wypożyczalni aut Read More »\nDlaczego warto korzystać z rehabilitacji?\nW dzisiejszych czasach ludzie prowadzą coraz bardziej siedzący tryb życia. Nawet jeżeli dbają o to, aby codziennie uprawiać jakiś sport, to zazwyczaj mogą na to poświęcić małą ilość czasu w porównaniu do tej, którą muszą poświęcać na pracę. W pracy natomiast niemal cały czas przebywają w pozycji siedzącej, co powoduje wiele skutków, z którymi nawet …\nDlaczego warto korzystać z rehabilitacji? Read More »\nWarto mieć taśmę klejącą\nBy Teresa Szewczyk\nNiektóre rzeczy są bardzo znane na całym świecie i nie chodzi mi tutaj tylko i wyłącznie o coś dużego, czyli na przykład samochody, bo przecież to jest dość oczywiste. Dotyczy to również rzeczy pozornie niewielkich, bo są dużo istotniejsze, niż by się na pierwszy rzut oka wydawało. Tak jest właśnie z taśmami klejącymi, gdyż …\nWarto mieć taśmę klejącą Read More »\nModne parasole w naszych ogrodach\nBy Damian Sikor\nZbliża się lato, co widać po aurze za oknem. Dni są coraz cieplejsze i pełne słońca. A ludzie masowo zaczęli przygotowywać do tej pięknej pory roku swoje ogrody. Sadzi się więc rośliny, sieje kwiaty, a także stawia się różnego rodzaju meble ogrodowe. Nasze ogrody mają od jakiegoś czasu bardzo ważną funkcję. Są mianowicie miejscem spotkań …\nModne parasole w naszych ogrodach Read More »


Rolex Oyster Perpetual Yacht-Master II [Baselworld 2017] – Zegarki i Pióra\nYacht-Master II z pewnością nie należy do typowych czasomierzy, które plasują się w czołówkach list sprzedażowych danego producenta. Nic dziwnego – model ten pełni zupełnie inną funkcję wizerunkową. Praktycznie każdy istotny gracz w tej branży, który znany jest z zegarków dedykowanych dla osób mających kontakt z morzem (oczywiście na dzień dzisiejszy trzeba już wziąć na to stwierdzenie pewną poprawkę), ma w ofercie nie tylko zegarki dedykowane dla nurków, ale i czasomierze wyposażone w komplikacje dedykowane regatom żeglarskim. W taką właśnie funkcję wyposażono tytułowy model.\nPierścień lunety działa dwukierunkowo w zakresie 90 stopni. Przy jego pomocy możemy ustawiać czas, który przeznaczony jest na przygotowania, a po którym rusza właściwa część regat. Odliczanie możemy ustawić w zakresie od 1 do 10 minut. Co ciekawe – producent skonstruował ową komplikację tak, że posiada ona tzw. „pamięć mechaniczną”, tj. nie musimy każdorazowo jej ustawiać od samego początku. Co więcej po powrocie bezela do ustawienia wyjściowego, mechanizm wciąż „wie”, jaka wartość została ustawiona (najlepiej obrazuje to film przygotowany przez producenta). Wkładka obrotowego pierścienia lunety wykonana jest z ceramiki Cerachrom w kolorze niebieskim. Cyfry oraz litery zostały wypełnione platyną, która nanoszona jest w procesie napylania magnetronowego.\nTrzeba zresztą przyznać, że zarówno kolorystyka, jak i kompozycja cyferblatu modelu Yacht-Master mocno utrwaliły się już w świecie zegarków mechanicznych. Niebiesko-biała kolorystyka tarczy w udany sposób kontynuuje barwę pierścienia umieszczonego na bezelu. Akcenty w kolorze czerwonym atrakcyjnie „ożywiają” całą kompozycję. Szkieletowane, centralnie osadzone wskazówki (minutowa oraz godzinowa) podobnie jak kwadratowe indeksy godzinowe otrzymały wypełnienie z substancji Chromalight. Wspomniane wskazówki wykonano z 18 karatowego białego złota. Tarczę chroni szkło szafirowe.\nWykonana ze stali 904L koperta mierzy 44mm średnicy. Jej kształty są typowe dla linii nazywanej przez Rolexa „Oyster”. Producent deklaruje, że cała zasadnicza część koperty jest monoblokiem. Z jej prawej strony umieszczono zakręcaną koronkę (wyposażoną w system Triplock) oraz przyciski służące do obsługi głównych funkcji zegarka. Wodoodporność została przez producenta określona na poziomie 100 metrów.\nManufakturowy kaliber 4161 jest wyposażony w automatyczny naciąg sprężyny, koło kolumnowe oraz pionowe sprzęgło. Bazuje on na kalibrze 4130, który w 2000 roku został opracowany dla modelu Cosmograph Daytona. Werk ten oferuje rezerwę chodu wynoszącą 72 godziny chodu. Do łożyskowania ruchomych elementów użyto 42 rubinów. Mechanizm ten pracuje z częstotliwością chodu wynoszącą 4Hz (28800VpH).\nZegarek ten oferowany jest na trój-segmentowej bransolecie typu „Oyster”, która wykonana jest z tego samego materiału co koperta (stal 904L). Podobnie jak koperta, także i bransoleta łączy powierzchnie szczotkowane oraz polerowane na wysoki połysk.\nTagi: 2017, Basel, Baselworld, Baselworld 2017, Master, Oyster, Perpetual, Rolex, Watch, watches, Yacht, Yacht-Master II, zegarek, zegarki\nFundacja Wisławy Szymborskiej – Pomagaj pisarzom, wspieraj młodych twórców!


Chcesz uruchomić własną firmę? Wybierz sklep internetowy! - Informacje i ciekawostki\n/Chcesz uruchomić własną firmę? Wybierz sklep internetowy!\nTworzenie sklepów internetowych to działalność, którą zajmują się profesjonalne firmy. Założenie sklepu oferującego sprzedaż internetową nie jest bowiem łatwe. Zanim jednak zlecimy komuś założenie dla nas sklepu internetowego, powinniśmy się bardzo poważnie zastanowić nad tym, co planujemy w nim sprzedawać. Jest to bowiem najbardziej elementarna wiedza, która potrzebna jest wszystkim tym, którzy w swojej ofercie posiadają tworzenie sklepów internetowych. Pomysłów na sprzedawane produkty jest naprawdę mnóstwo. Może to być odzież w różnym stylu, książki, płyty. Proponować swoim klientom można sprzęt AGD, a nawet jedzenie. Dzisiaj naprawdę wszystko może znaleźć klientów – Tworzenie sklepów internetowych najlepiej polecić doświadczonej i wykwalifikowanej firmie, która doskonale wie, co robi. Na ogół tworzenie sklepów internetowych zaczyna się od wybrania nazwy sklepu oraz domeny. Trzeba się nad tym solidnie zastanowić ponieważ jest to decyzja na naprawdę długo. Nazwa sklepu powinna prosto mówić, co w sklepie oferujemy. Domena musi do niej prosto nawiązywać. Potem przychodzi pora na wybór dopasowanego oprogramowania. To od niego będzie zależało, czy sklep będzie działał bez zbędnych problemów.\nJeśli stwierdzisz, że umieszczone w tym tekście informacje są warte uwagi, zobacz dodatkowo szczegóły w linku stoliki kawowe metalowe. Będą tam równie przydatne dane.\nAby nie zabrakło klientów, sklep działający w Internecie musi być dostępny dla klientów dwadzieścia cztery godziny na dobę, a jego strona musi działać bez żadnego zacinania się. Jeżeli tak nie będzie, klienci szybko znikną. Koniecznie powinno również zastanowić się nad wyborem szaty graficznej. Musi ona być przyjemna dla oka, a jednocześnie musi nawiązywać do oferty sklepu. Sprzedając na przykład odzież niemowlęcą, lepiej nie decydować się na czarne kolory. Nie będą one kojarzyły się dobrze. Podobnie, jeżeli sprzedawać zamierza się zdrową żywność. Barwy powinny być dobrane także tak, aby korzystanie ze sklepu nie było utrudnione. Różowe litery na na tle o zielonej barwie nie są z pewnością dobrym wyborem.\nAGD, biznes, odzież, pieniądze


Dziennik Ustaw Nr 10, poz. 98 z 2002 - Strona 2 - e-prawnik.pl\nDziennik Ustaw Nr 10, poz. 98 z 2002 - Strona 2\nTreść dokumentu: Dziennik Ustaw Nr 10, poz. 98 z 2002 - Strona 2\nDziennik Ustaw Nr 10 — 627 — Poz. 98\nZałącznik do rozporządzenia Ministra Infrastruktury z dnia 25 stycznia 2002 r. (poz. 98)\nTABELA OPŁAT ZA BADANIA TECHNICZNE POJAZDÓW Opłata w zł (zawiera podatek od towarów i usług VAT)1) 3\n1 1 1.1 1.2 Okresowe badanie techniczne: — motocykl, ciągnik rolniczy\n— samochód osobowy, autobus przeznaczony do przewozu nie więcej niż 15 osób łącznie z kierowcą, samochód ciężarowy i specjalny do 3,5 t d.m.c., pojazd trójkołowy powyżej 0,4 t m.w.2) — samochód ciężarowy i specjalny, ciągnik samochodowy siodłowy powyżej 3,5 t do 16 t d.m.c. — samochód ciężarowy i specjalny, ciągnik samochodowy siodłowy powyżej 16 t d.m.c., ciągnik samochodowy balastowy — autobus przeznaczony do przewozu więcej niż 15 osób łącznie z kierowcą — przyczepa ciężarowa rolnicza do 1,5 t d.m.c. — przyczepa ciężarowa rolnicza powyżej 1,5 t do 6 t d.m.c. — przyczepa ciężarowa rolnicza powyżej 6 t d.m.c. — przyczepa (naczepa) ciężarowa i specjalna do 3,5 t d.m.c. — przyczepa (naczepa) ciężarowa i specjalna powyżej 3,5 t do 16 t d.m.c. — przyczepa (naczepa) ciężarowa i specjalna powyżej 16 t d.m.c. — pojazd przeznaczony do przewozu materiałów niebezpiecznych (za badanie specjalistyczne) — taksówka osobowa lub bagażowa (za warunki dodatkowe) — pojazd uprzywilejowany (za warunki dodatkowe) — pojazd przystosowany do zasilania gazem (za badanie specjalistyczne) — pojazd przystosowany do nauki jazdy lub do przeprowadzania egzaminu państwowego (za warunki dodatkowe) — tramwaj — wagon silnikowy3) — tramwaj — wagon przegubowy3) — tramwaj — wagon doczepny czynny3) — tramwaj — wagon doczepny bierny3) — trolejbus — badania elektryczne3) 4)\n92,00 148,00 170,00 192,00 40,00 50,00 70,00 75,00 157,00 171,00 82,00 42,00 50,00 63,00 48,00 330,00 395,00 250,00 110,00 115,00\n1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21\nPonowne sprawdzenie mechanizmów i zespołów w pojeździe, w którym stwierdzono usterki w trakcie badań technicznych w zakresie: — skuteczności i równomierności działania hamulców — skuteczności działania hamulców tramwaju3) — skuteczności działania hamulca elektrodynamicznego trolejbusu3) 20,00 120,00 50,00\nDziennik Ustaw Nr 10, poz. 98 z 2002 - Strona 2 - pozostałe dokumenty:


listopada 2013 ~ ZIEMIA FRYSZTACKA\nAkustyczne przeboje we Floriańskiej - koncert ACOUSTIC SPACE\nponiedziałek, listopada 25, 2013 Imprezy Brak komentarzy\nZapraszamy wszystkich mieszkańców Gminy Frysztak na wspaniały koncert akustyczny, który odbędzie się w restauracji Floriańska we Frysztaku. Dla wszystkich zgromadzonych zagra duet młodych, zdolnych gitarzystów - Artur Bradliński i Grzegorz Drogoń, którzy tworzą formację ACOUSTIC SPACE i grają utwory szeroko rozumianej muzyki rozrywkowej w aranżacjach akustycznych, przekazując tym samym niecodzienny klimat sprzyjający spotkaniom towarzyskim okraszonych niebanalną aurą utworów polskich jak i zagranicznych.\nW repertuarze ACOUSTIC SPACE znajdują się utwory wykonawców takich jak: The Beatles, Stevie Wonder, Michael Bubble, Sting, Michael Jackson, Eric Clapton, Adele, Elvis Presley, Perfect, Stanisław Soyka, Dżem.. i wiele innych.\nKoncert zespołu ACOUSTIC SPACE odbędzie się w PIĄTEK 29 listopada o godzinie 19.00\nDla niezdecydowanych poniżej pierwszy klip zespołu ACOUSTIC SPACE - Wherever you will go (The Calling cover)\nP.S. Ciekawe czy poznacie gdzie był nagrywany :)\nOrganizatorem akustycznego spotkania w Restauracji Floriańska jest Ziemia Frysztacka - Stowarzyszenie Promocji i Rozwoju.\nXXII finał WOŚP na sportowo i koncertowo ! Rejestracja wolontariuszy rozpoczęta !\nśroda, listopada 13, 2013 WOŚP Brak komentarzy\nRuszyliśmy z przygotowaniami do XXII finału Wielkiej Orkiestry Świątecznej Pomocy, który odbędzie się 12 stycznia 2014 roku. Tym razem będziemy zbierać pieniądze na zakup specjalistycznego sprzętu dla dziecięcej medycyny ratunkowej i godnej opieki medycznej seniorów.\nFrysztacki Finał zagramy na sportowo. Tego dnia mieszkańcy naszej gminy będą mogli wziąć udział w trzech turniejach: koszykówki, siatkówki i piłki nożnej. Zawody zorganizowane zostaną na trzech salach sportowych, więc czasu i miejsca na zmagania nie zabraknie. Więcej szczegółów już wkrótce na oficjalnej stronie sztabu Frysztak – wosp.frysztak24.pl\nJuż dziś zapraszamy Państwa również na kolejną edycję tradycyjnego biegu „Policz się z cukrzycą”. Przed nami już trzecia odsłona tego wspaniałego biegu, który tym razem odbędzie się na terenie Gminnego Ośrodka Sportu i Rekreacji. Biegniemy dla dobrej zabawy i rekreacji, a więc drodzy biegacze - bez względu na wiek i predyspozycje sportowe, zapraszamy na start!\nDla lubiących zimowe szaleństwa zorganizujemy również bieg na nartach, a dla najmłodszych zabawy na śniegu. Oby pogoda dopisała!\nWieczorem zaprosimy Państwa na teren Gminnego Ośrodka Sportu i Rekreacji we Frysztaku, gdzie odbędą się finałowe koncerty. Mamy nadzieję, że rozgrzeją one wszystkich, również tych, którzy tego dnia nie zdążyli wziąć udziału w gorących zmaganiach sportowych.\nXXII Finał WOŚP we Frysztaku uwieńczymy o godzinie 20:00 tradycyjnym „światełkiem do nieba”, czyli pokazem sztucznych ogni. Oj, będzie się działo!\nProgram obchodu frysztackiego Finału nie jest zamknięty! Jeżeli mają Państwo ciekawe pomysły na wspólne spędzenie tego wyjątkowego dnia, piszcie do nas: wosp@frysztak24.pl\nZapraszamy gorąco do częstego odwiedzania WOŚPowej strony frysztackiego sztabu – www.wosp.frysztak24.pl.\nXXII Finał WOŚP we Frysztaku odbędzie się pod patronatem Wójta Gminy Frysztak.\nZIEMIA FRYSZTACKA - Stowarzysznie Promocji i Rozwoju,\nGminny Zakład Komunalny we Frysztaku,\nGminna Biblioteka Publiczna we Frysztaku\nSzkoła Podstawowa we Frysztaku,\nSpecjalny Ośrodek Szkolno - Wychowawczy we Frysztaku.\nPortal Mieszkańców dla Mieszkańców Gminy Frysztak - Frysztak24.pl patronuje medialnie XXII finałowi Wielkiej Orkiestry Świątecznej Pomocy we Frysztaku\nAkustyczne przeboje we Floriańskiej - koncert ACOU...\nXXII finał WOŚP na sportowo i koncertowo ! Rejestr...