I’ll GET some REST and you keep me POSTed

PL

Wstęp

Dzisiaj chciałbym powiedzieć Wam o Web Services. Jest to bardzo obszerne pojęcie jeśli chodzi o środowisko .NET.

Web service jest usługą sieciową, czyli usługą udostępnioną w ramach sieci www w celu odbierania i dostarczania określonych danych, w określony sposób, przez określony protokół.

Najczęściej stosowanymi web service’ami są te wykorzystujące SOAP i REST.

SOAP, a REST

SOAP

SOAP, czyli Simple Object Access Protocol, to protokół dostępu od dawna już funkcjonujący w ramach .NET i nie tylko. SOAP pozwala na komunikację między web service’ami za pomocą wielu protokołów, takich jak TCP, HTTP i innych. Jest on bardzo rozbudowany, co często można uznać za wadę, biorąc pod uwagę rozwijane i popularne frameworki i interfejsy, które dążą do jak największego uproszczenia komunikacji między serwisami, choćby Web API.

Service References

Web Service oparty o SOAP budowany jest na podstawie tzw. Service References, które dostarczane są z zewnętrznego serwisu w celu oprogramowania odpowiedniej logiki do komunikacji z nim.

SOAP posiada też wiele innych funkcjonalności, które w codziennym programowaniu web service’ów nie jest raczej wykorzystywane.

WCF

Bardzo popularną platformą pozwalającą na tworzenie web service’ów jest WCF, czyli Windows Communication Foundation. WCF jako platforma wyposażona w API’s – Application Programming Interface – pozwala nie tylko na budowanie web service’ów ale także aplikacji o charakterze serwisów, czyli tzw. service-oriented applications.

Głównym formatem za pomocą, którego przesyłane są dane w ramach SOAP jest XML – Extensible Markup Language.

REST

REST, czyli Representational State Transfer, to protokół dostępu dużo młodszy od SOAP, który zyskał w ostatnich kilkunastu latach ogromną popularność, przede wszystkim dzięki swojej elastyczności oraz lekkości w używaniu.

REST w odróżnieniu od SOAP, korzysta tylko z protokołu komunikacyjnego HTTP.

Metody

W ramach REST dostępnych jest wiele metod odpowiadających za poszczególne operacje na danych. Są to m. in. POST, GET, PUT czy DELETE. POST powinno stosować jedynie do tworzenia nowego zasobu, GET odpowiada za pobieranie danych, PUT za aktualizację danych, a DELETE – co oczywiste – za usuwanie zasobów.

Oczywiście można np. za pomocą metody POST zaktualizować dane ale to nie jest to zalecana praktyka i warto trzymać się zalecanej konwencji.

Kiedyś na rozmowę kwalifikacyjnej dostałem pytanie na temat różnicy między metodą GET i POST, bo przecież zarówno za pomocą GET i POST można pobrać dane i je zaktualizować – to prawda, ale różnica nie leży w samej konwencji ale w syntaktyce. GET opiera się wyłącznie na adresie URL i parametry przekazać można jedynie w jego treści, POST natomiast do przesłania danych wykorzystuje zarówno adres jak i body, czyli zestaw atrybutów i ich wartości – w zdecydowanej większości przypadków – w formacie JSON.

Przykładowe wywołanie metody GET w celu otrzymania listy zakupów z koszyka:

adres url: https://www.nameoftheonlineshop/cart/products

Przykładowe wywołanie metody POST w celu dodania nowego produktu do koszyka:

adres url: https://www.nameoftheonlineshop/cart/add

body:


{

"name":"t-shirt"

"price":20,00

"quantity":1

}

Web API

Z REST korzystają takie interfejsy jak Web API, czy Web API 2.0, czyli bardzo popularne technologie .NET pozwalające na tworzenie usług sieciowych oparte o mechanizm kontrolerów, dobrze znanym programistom, którzy pracowali nad takimi wzorcami architektonicznymi jak MVC, czy MVVM.

Głównym formatem, dzięki któremu odbywa się przesyłanie danych jest JSON – Java Script Object Notation.

Kiedy REST, a kiedy SOAP?

Ciężko wprost odpowiedzieć na to pytanie, kiedy stosować SOAP, a kiedy REST. Prawdopodobnie w większości sytuacji to wykorzystywana technologia w projekcie wskaże nam drogę, no chyba, że to my mamy decydować o technologii projektu. Wtedy powinniśmy zastanowić się przede wszystkim, z jakimi serwisami będziemy chcieli komunikować się poprzez nasz web service oraz nad tym, w jakich frameworkach i obszarach czujemy się dobrze, czy jest to WCF, czy może Web API, czy może inne.

Podsumowanie

Web service’y są filarem aplikacji webowych. Zdecydowana większość aplikacji webowych komunikuje się z jakąś usługą sieciową w różnych celach i zarówno programiści front-end jak i back-end mają do czynienia z web service’ami codziennie.

Wróć na stronę startową

ENG

Introduction

Today I will tell you about Web Services. It is very complex notion according to the .Net platform.

Web service is a service delivered within a web, published within www network in order to receive and deliver data in desirable way and via desirable protocol.

The most popular web services are these using SOAP and REST.

SOAP vs REST

SOAP

SOAP, which is Simple Object Access Protocol, is the access protocol that has been functioning for some time within .NET and others frameworks. SOAP allows to communicate between web services using many protocols such as TCP, HTTP and others. It is very complex, which some time is a disadvantage especially according to the popular frameworks and interfaces being developed which are going to be as easy in communication as possible e.g. Web Api interface.

Service References

Web service using SOAP protocol is built basing on so called Service References, which are delivered from an external service in order to program proper logic being necessary to communication reasons.

SOAP has got many others functionalities which are not so often used in developing web services.

WCF

Very popular platform which allows to create web services within .NET is WCF, which is Windows Communication Foundation. Leaving web services aside, WCF as a API’s – Application Programming Interface – set is also used to build service-oriented applications.

Main format by which in SOAP sending data is performed is XML– Extensible Markup Language.

REST

REST, which is Representational State Transfer, is the access protocol much younger than SOAP. REST has becoming more and more popular for a couple of years, mainly due its flexibility and ease in use.

REST, as distinct from SOAP, uses only one protocol and it is HTTP protocol.

Methods

Within REST many methods responsible for performing particular operations on data are available. Mainly there are POST, GET, PUT or DELETE verbs. POST should be used for creating data, GET is responsible for reading data, PUT for updating and DELETE – which is obvious – for deleting data.

Of course it is possible to update data using POST method but it is not advised practice and it is desired to follow advised conventions.

I remember some time ago, on the job interview i was asked about difference between GET and POST methods, because we can get and update date using both of them – that is truthbut the difference is not about convention but about syntax. GET is based only on the URL and the only way to pass parameters is by request address whereas POST uses both address and body which is set of attributes and its values – in the most of cases – in JSON format.

Example of invoking GET method in order to get list of products from cart:

url: https://www.nameoftheonlineshop/cart/products

Example of invoking POST method in order to add new product to cart:

url: https://www.nameoftheonlineshop/cart/add

body:


{

"name":"t-shirt"

"price":20,00

"quantity":1

}

Web API

REST is used by such interfaces as Web API or Web API 2.0 which are very popular .NET technologies allowing to create web services with controllers’mechanisms that are well-knowns by those developers who have worked with such architectonic patterns as MVC or MVVM.

The main format by which in REST sending data is preformed is JSON – Java Script Object Notation.

When to use REST/SOAP?

It is hard to answer this question. Probably in the most of cases it is technology used in project that indicates direction not our decision. When decision is in our hands it is worth to think about what services we are going to communicate with and about what frameworks and areas we feel comfortable in, is it quite complex WCF or more light Web API or others.

Summary

Web Services are the keystone of the web applications. Most of the web applications communicate with some web service due to many reasons and both, front-end and back-end programmers, deal with web services every day.

Get back to Home Page

4 komentarze do wpisu „I’ll GET some REST and you keep me POSTed

  1. „GET opiera się wyłącznie na adresie URL i parametry przekazać można jedynie w jego treści, POST natomiast do przesłania danych wykorzystuje zarówno adres jak i body, czyli zestaw atrybutów i ich wartości”

    Ja tu bardziej kieruję się idempotencją – GET jest, a POST nie, aczkolwiek znajdą się osoby które robią jeszcze inaczej… 😉

  2. Dla mnie wybór jest prosty: SOAP tylko i wyłącznie w wypadku gdy nie ma REST api (legacy code). W przeciwnym wypadku REST, gdy wymagana jest duża elastyczność to GraphQL.

  3. Pingback: dotnetomaniak.pl

Dodaj komentarz