![{"menu": {!
"id": "file",!
"value": "File",!
"popup": {!
"menuitem": [!
{"value": "New", "onclick":
"CreateNewDoc()"},!
{"value": "Open", "onclick":
"OpenDoc()"},!
{"value": "Close", "onclick":
"CloseDoc()"}!
]!
}!
}}](https://image.slidesharecdn.com/prezka-api-140626032315-phpapp01/75/JSON-REST-API-4-2048.jpg)
JSON, REST API
- 1. Oskar Szrajer! Modern API http://gotar.infooskarszrajer@gmail.com
- 2.
- 3. JSON JSON, JavaScript ObjectNotation (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()"}! ]! }! }}
- 5.
- 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
- 7.
- 8.
- 9. Rodzaje aplikacji • monolityczne •modularne
- 11.
- 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 statuscodes! & 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 resourceswhere 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 willnot include the full resource representation, e.g.:
- 16. Provide resource (UU)IDs! & Giveeach 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! & Providecreated_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 timesformatted 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! & Generateconsistent, 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 keyrelations
- 21. • Use consistentpath 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 toDSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalnym nakładem pracy $ app.rb
- 24. Sinatra (http://www.sinatrarb.com) Sinatra toDSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalną nakładem pracy ilością kodu $ app.rb
- 25. RACK http://rack.github.io Rack providesa 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 &
- 26. RACK http://rack.github.io You canhandle an app directly:
- 27. Sinatra (http://www.sinatrarb.com) Sinatra toDSL do szybkiego tworzenia aplikacji webowych w Ruby z minimalną nakładem pracy ilością kodu $ app.rb $ config.ru
- 28. Sinatra contrib https://github.com/rkh/sinatra-contrib sinatra/json: Addsa #json helper method to return JSON documents.
- 29.