SlideShare a Scribd company logo
Oskar Szrajer!
Modern API
http://gotar.info oskarszrajer@gmail.com
JSON
JSON
JSON, JavaScript Object Notation (wym. ˈdʒeɪsən) – lekki
format wymiany danych komputerowych. JSON jest
formatem tekstowym, będącym podzbiorem języka
JavaScript. Typ MIME dla formatu JSON to application/
json. Format został opisany w dokumencie RFC 4627.
{"menu": {!
"id": "file",!
"value": "File",!
"popup": {!
"menuitem": [!
{"value": "New", "onclick":
"CreateNewDoc()"},!
{"value": "Open", "onclick":
"OpenDoc()"},!
{"value": "Close", "onclick":
"CloseDoc()"}!
]!
}!
}}
REST
REST
Representational State Transfer – wzorzec architektury oprogramowania wywiedziony z
doświadczeń przy pisaniu specyfikacji protokołu HTTP. REST jest wzorcem architektury
oprogramowania wprowadzającym dobre praktyki tworzenia architektury aplikacji rozproszonych.&
REST wprowadza terminy takie jak jednorodny interfejs, bezstanowa komunikacja, zasób,
reprezentacja.&
&
Zaproponowany przez Roya T. Fieldinga w 2000 roku.&
&
Jest wykorzystywany przez wiele frameworków aplikacji internetowych np. Jersey, Ruby on Rails,
Apache Sling, Sinatra, Django, RESTlet, RESTeasy i wiele innych.&
Charakterystycznym elementem REST jest "restowy" (RESTful) interfejs usług webowych, w którym
parametry wywołania danej usługi są umieszczane w ścieżce adresu URL, a nie w części
przeznaczonej na parametry, jak w klasycznych wywołaniach GET lub POST:&
&
Wywołanie klasyczne&
http://example.com/article?id=1234&format=print!
&
Wywołanie RESTful&
http://example.com/article/1234/print
Rodzaje aplikacji
Rodzaje aplikacji
• monolityczne
Rodzaje aplikacji
• monolityczne
• modularne
JSON, REST API
API
API
Interfejs programowania aplikacji (ang. Application Programming
Interface, API) – sposób, rozumiany jako ściśle określony zestaw reguł i
ich opisów, w jaki programy komunikują się między sobą. API definiuje
się na poziomie kodu źródłowego dla takich składników
oprogramowania jak np. aplikacje, biblioteki czy system operacyjny.
Zadaniem API jest dostarczenie odpowiednich specyfikacji
podprogramów, struktur danych, klas obiektów i wymaganych
protokołów komunikacyjnych.
Return appropriate status codes!
&
Return appropriate HTTP status codes with each response.
Successful responses should be coded according to this guide:
&
• 200: Request succeeded for a GET calls, and for DELETE or PATCH calls that
complete synchronously
• 201: Request succeeded for a POST call that completes synchronously
• 202: Request accepted for a POST, DELETE, or PATCH call that will be processed
asynchronously
• 206: Request succeeded on GET, but only a partial response returned: see above
on ranges
Provide full resources where available!
&
Provide the full resource representation (i.e. the object with all
attributes) whenever possible in the response. Always provide the full
resource on 200 and 201 responses, including PUT/PATCH and
DELETE requests, e.g.:
202 responses will not include the full resource representation, e.g.:
Provide resource (UU)IDs!
&
Give each resource an id attribute by default. Use UUIDs unless you have a
very good reason not to. Don’t use IDs that won’t be globally unique across
instances of the service or other resources in the service, especially auto-
incrementing IDs.
&
Render UUIDs in downcased 8-4-4-4-12 format, e.g.:
"id": "01234567-89ab-cdef-0123-456789abcdef"
Provide standard timestamps!
&
Provide created_at and updated_at timestamps for resources by default, e.g:
These timestamps may not make sense for some resources, in which case they can be omitted.
Use UTC times formatted in ISO8601!
&
Accept and return times in UTC only. Render times in ISO8601 format, e.g.:
&
"finished_at": "2012-01-01T12:00:00Z"
Generate structured errors!
&
Generate consistent, structured response bodies on errors. Include a machine-
readable error id, a human-readable error message, and optionally a url pointing
the client to further information about the error and how to resolve it, e.g.:
Nest foreign key relations
• Use consistent path formats
• Downcase paths and attributes
• Support caching with Etags
• Trace requests with Request-Ids
• Paginate with Ranges
• Show rate limit status
• Minimize path nesting
• Provide machine-readable JSON schema
• Provide human-readable docs
• Provide executable examples
• Describe stability
• Require SSL
• Pretty-print JSON by default
API w RUBY
• Rails API - https://github.com/rails-api/rails-api
• Sinatra - https://github.com/sinatra/sinatra/
• Grape - https://github.com/intridea/grape
• Lotus - https://github.com/lotus
• …
Sinatra (http://www.sinatrarb.com)
Sinatra to DSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalnym
nakładem pracy
$ app.rb
Sinatra (http://www.sinatrarb.com)
Sinatra to DSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalną
nakładem pracy ilością kodu
$ app.rb
RACK http://rack.github.io
Rack provides a minimal interface between webservers
supporting Ruby and Ruby frameworks.
To use Rack, provide an "app": an object that responds to the
call method, taking the environment hash as a parameter,
and returning an Array with three elements:
• The HTTP response code
• A Hash of headers
• The response body, which must respond to each
&
RACK http://rack.github.io
You can handle an app directly:
Sinatra (http://www.sinatrarb.com)
Sinatra to DSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalną
nakładem pracy ilością kodu
$ app.rb
$ config.ru
Sinatra contrib
https://github.com/rkh/sinatra-contrib
sinatra/json: Adds a #json helper method to return JSON documents.
Pytania?

More Related Content

PDF
Architektura rest
PDF
Budowa RESTowego api w oparciu o HATEOAS
PDF
Master Thesis - Comparative analysis of programming Environments based on Rub...
PDF
Api design - slajdy
PDF
Rails 2 - web aplikacje bardziej subiektywnie
PDF
Budowa poprawnego i intuicyjnego api REST HATEOAS devfest@2013
PPTX
Android i REST
PPTX
Ruby on rails wprowadzenie teoretyczne. Łukasz Szyndzielorz
Architektura rest
Budowa RESTowego api w oparciu o HATEOAS
Master Thesis - Comparative analysis of programming Environments based on Rub...
Api design - slajdy
Rails 2 - web aplikacje bardziej subiektywnie
Budowa poprawnego i intuicyjnego api REST HATEOAS devfest@2013
Android i REST
Ruby on rails wprowadzenie teoretyczne. Łukasz Szyndzielorz

Similar to JSON, REST API (20)

PDF
Microservieces and their communication (RabbitMQ/SIDEKIQ)
PDF
Ruby on Rails -- czy warto?
PDF
Tech cafe Microservices
PDF
OSGi, deklaratywnie
PDF
Produkcja aplikacji internetowych
PPTX
Testowanie na 101 sposobów
PDF
Paleta możliwości web developera
PDF
Lionframe - Rapid RESTful API development
PDF
Design Modern API - The Right Way
PPT
Extjs & netzke
PDF
Rails tobak2005
PDF
REST API - teoria i praktyka - WordUp Warszawa
PDF
Modsecurity-czy-Twoj-WAF-to-potrafi-Leszek-Mis-Linux-Polska
PPTX
Mts 2013 tomasz kopacz - windows 8, office 365, workflow manager, windows a...
PDF
Michał Dec - Quality in Clouds
PPTX
Z czym do api
PDF
Porażka nie wchodzi w grę, czyli o niezawodności
PDF
Ruby on Rails. Aplikacje webowe
PDF
Rest security
PDF
Język Ruby - wprowadzenie
Microservieces and their communication (RabbitMQ/SIDEKIQ)
Ruby on Rails -- czy warto?
Tech cafe Microservices
OSGi, deklaratywnie
Produkcja aplikacji internetowych
Testowanie na 101 sposobów
Paleta możliwości web developera
Lionframe - Rapid RESTful API development
Design Modern API - The Right Way
Extjs & netzke
Rails tobak2005
REST API - teoria i praktyka - WordUp Warszawa
Modsecurity-czy-Twoj-WAF-to-potrafi-Leszek-Mis-Linux-Polska
Mts 2013 tomasz kopacz - windows 8, office 365, workflow manager, windows a...
Michał Dec - Quality in Clouds
Z czym do api
Porażka nie wchodzi w grę, czyli o niezawodności
Ruby on Rails. Aplikacje webowe
Rest security
Język Ruby - wprowadzenie
Ad

More from 3camp (20)

PDF
Ochrona podatnych webaplikacji za pomocą wirtualnych poprawek
PDF
HTTPS bez wymówek
PPTX
Jak udokumentować bazę danych
PDF
ORM - tuningujemy podejście do mapowania
PDF
No pressure, no diamonds. Rzecz o łamaniu zasad w projektach.
PDF
W poszukiwaniu procesu doskonałego. Wdrożenie Scruma, Continuous Integrations...
PDF
Wykorzystanie języka Kotlin do aplikacji na platformie Android
PDF
Learn you some rx for the greater good
PDF
Google App Engine i Google Play Services w Twoich aplikacjach
PDF
Reakcja łańcuchowa, czyli React.js w praktyce
PDF
Odtwarzanie multimediów w HTML5, czyli Player przez duże „P”
PPTX
AngularJS (nie) nadaje się do dużego projektu
PDF
Przemysław Bartkowiak - Sam ustalasz ile za to zapłacisz – czyli nowy wymiar ...
PDF
Mirek Wąsowicz - Segment jednego, dokąd zmierza marketing online?
PDF
Artur Senk, OKE Poland, Big Data na zakupach
PDF
Piotr Macuk, Konfeo.com, Programista i biznes – plusy i minusy własnej działa...
PPTX
Marcin Maj, Kainos - QA – wartko, zmiennie i interdyscyplinarnie
PDF
Jak przesiąść się na rower na dwóch kółkach? Od trzyosobowego startupu do spó...
PDF
Łukasz Brzeziński - Jak zarabiać z Wikingami? Czyli monetyzacja portalu inter...
PDF
Marcin Szeląg, InnovationNest, Startup Risk Model
Ochrona podatnych webaplikacji za pomocą wirtualnych poprawek
HTTPS bez wymówek
Jak udokumentować bazę danych
ORM - tuningujemy podejście do mapowania
No pressure, no diamonds. Rzecz o łamaniu zasad w projektach.
W poszukiwaniu procesu doskonałego. Wdrożenie Scruma, Continuous Integrations...
Wykorzystanie języka Kotlin do aplikacji na platformie Android
Learn you some rx for the greater good
Google App Engine i Google Play Services w Twoich aplikacjach
Reakcja łańcuchowa, czyli React.js w praktyce
Odtwarzanie multimediów w HTML5, czyli Player przez duże „P”
AngularJS (nie) nadaje się do dużego projektu
Przemysław Bartkowiak - Sam ustalasz ile za to zapłacisz – czyli nowy wymiar ...
Mirek Wąsowicz - Segment jednego, dokąd zmierza marketing online?
Artur Senk, OKE Poland, Big Data na zakupach
Piotr Macuk, Konfeo.com, Programista i biznes – plusy i minusy własnej działa...
Marcin Maj, Kainos - QA – wartko, zmiennie i interdyscyplinarnie
Jak przesiąść się na rower na dwóch kółkach? Od trzyosobowego startupu do spó...
Łukasz Brzeziński - Jak zarabiać z Wikingami? Czyli monetyzacja portalu inter...
Marcin Szeląg, InnovationNest, Startup Risk Model
Ad

JSON, REST API

  • 3. JSON JSON, JavaScript Object Notation (wym. ˈdʒeɪsən) – lekki format wymiany danych komputerowych. JSON jest formatem tekstowym, będącym podzbiorem języka JavaScript. Typ MIME dla formatu JSON to application/ json. Format został opisany w dokumencie RFC 4627.
  • 4. {"menu": {! "id": "file",! "value": "File",! "popup": {! "menuitem": [! {"value": "New", "onclick": "CreateNewDoc()"},! {"value": "Open", "onclick": "OpenDoc()"},! {"value": "Close", "onclick": "CloseDoc()"}! ]! }! }}
  • 6. REST Representational State Transfer – wzorzec architektury oprogramowania wywiedziony z doświadczeń przy pisaniu specyfikacji protokołu HTTP. REST jest wzorcem architektury oprogramowania wprowadzającym dobre praktyki tworzenia architektury aplikacji rozproszonych.& REST wprowadza terminy takie jak jednorodny interfejs, bezstanowa komunikacja, zasób, reprezentacja.& & Zaproponowany przez Roya T. Fieldinga w 2000 roku.& & Jest wykorzystywany przez wiele frameworków aplikacji internetowych np. Jersey, Ruby on Rails, Apache Sling, Sinatra, Django, RESTlet, RESTeasy i wiele innych.& Charakterystycznym elementem REST jest "restowy" (RESTful) interfejs usług webowych, w którym parametry wywołania danej usługi są umieszczane w ścieżce adresu URL, a nie w części przeznaczonej na parametry, jak w klasycznych wywołaniach GET lub POST:& & Wywołanie klasyczne& http://example.com/article?id=1234&format=print! & Wywołanie RESTful& http://example.com/article/1234/print
  • 11. API
  • 12. API Interfejs programowania aplikacji (ang. Application Programming Interface, API) – sposób, rozumiany jako ściśle określony zestaw reguł i ich opisów, w jaki programy komunikują się między sobą. API definiuje się na poziomie kodu źródłowego dla takich składników oprogramowania jak np. aplikacje, biblioteki czy system operacyjny. Zadaniem API jest dostarczenie odpowiednich specyfikacji podprogramów, struktur danych, klas obiektów i wymaganych protokołów komunikacyjnych.
  • 13. Return appropriate status codes! & Return appropriate HTTP status codes with each response. Successful responses should be coded according to this guide: & • 200: Request succeeded for a GET calls, and for DELETE or PATCH calls that complete synchronously • 201: Request succeeded for a POST call that completes synchronously • 202: Request accepted for a POST, DELETE, or PATCH call that will be processed asynchronously • 206: Request succeeded on GET, but only a partial response returned: see above on ranges
  • 14. Provide full resources where available! & Provide the full resource representation (i.e. the object with all attributes) whenever possible in the response. Always provide the full resource on 200 and 201 responses, including PUT/PATCH and DELETE requests, e.g.:
  • 15. 202 responses will not include the full resource representation, e.g.:
  • 16. Provide resource (UU)IDs! & Give each resource an id attribute by default. Use UUIDs unless you have a very good reason not to. Don’t use IDs that won’t be globally unique across instances of the service or other resources in the service, especially auto- incrementing IDs. & Render UUIDs in downcased 8-4-4-4-12 format, e.g.: "id": "01234567-89ab-cdef-0123-456789abcdef"
  • 17. Provide standard timestamps! & Provide created_at and updated_at timestamps for resources by default, e.g: These timestamps may not make sense for some resources, in which case they can be omitted.
  • 18. Use UTC times formatted in ISO8601! & Accept and return times in UTC only. Render times in ISO8601 format, e.g.: & "finished_at": "2012-01-01T12:00:00Z"
  • 19. Generate structured errors! & Generate consistent, structured response bodies on errors. Include a machine- readable error id, a human-readable error message, and optionally a url pointing the client to further information about the error and how to resolve it, e.g.:
  • 20. Nest foreign key relations
  • 21. • Use consistent path formats • Downcase paths and attributes • Support caching with Etags • Trace requests with Request-Ids • Paginate with Ranges • Show rate limit status • Minimize path nesting • Provide machine-readable JSON schema • Provide human-readable docs • Provide executable examples • Describe stability • Require SSL • Pretty-print JSON by default
  • 22. API w RUBY • Rails API - https://github.com/rails-api/rails-api • Sinatra - https://github.com/sinatra/sinatra/ • Grape - https://github.com/intridea/grape • Lotus - https://github.com/lotus • …
  • 23. Sinatra (http://www.sinatrarb.com) Sinatra to DSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalnym nakładem pracy $ app.rb
  • 24. Sinatra (http://www.sinatrarb.com) Sinatra to DSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalną nakładem pracy ilością kodu $ app.rb
  • 25. RACK http://rack.github.io Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks. To use Rack, provide an "app": an object that responds to the call method, taking the environment hash as a parameter, and returning an Array with three elements: • The HTTP response code • A Hash of headers • The response body, which must respond to each &
  • 27. Sinatra (http://www.sinatrarb.com) Sinatra to DSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalną nakładem pracy ilością kodu $ app.rb $ config.ru